Overview

I’m developing a SwiftUI iPad app that runs on an Apple silicon Mac as an iPad app—not as a Mac Catalyst app. The app supports multiple windows, with each Live Screen window associated with a different virtual machine. In the macOS Window menu, all child windows appear as “VirtualProg” rather than showing their content or VM name. The Live Screen window is created from a data-driven  WindowGroup , roughly like this: WindowGroup(id: "vm-screen", for: String.self) { $vmName in VMScreenWindow(vmName: vmName) .navigationTitle(vmName.map { "Live ($0)" } ?? "Live Screen") } I’ve tried setting the title with  .navigationTitle  both on the  WindowGroup  content and inside the window’s  NavigationStack . I also tried setting  windowScene.title  on the specific scene obtained from  view.window?.windowScene  after the view controller appeared. Neither changed the Window-menu entries. Is there a supported way to set a per-window title for the macOS Window menu when running an iPad app on Mac? Does  UIScene.title  affect that menu, or only the window title bar and app switcher? Is this a limitation of the iPad-app-on-Mac runtime, or is there a recommended SwiftUI/UIKit lifecycle hook for this? I’m looking for a public API solution rather than private AppKit/window introspection.

MapKit offers showsTraffic: Bool, which is great for displaying live traffic data on the map. However, MapPolyline sits above it, which makes it quite useless. Is this the expected behaviour?

I am seeing a reproducible Developer ID code-signing issue on an Apple Silicon Mac running macOS 26.6.2. A Universal macOS app and its Quick Look extension (arm64 + x86_64) are signed with a newly issued Developer ID Application certificate using Hardened Runtime and a secure timestamp. Immediately after signing, all verification succeeds, including: codesign --verify --strict --verbose=4 and architecture-specific verification for both arm64 and x86_64. At this point, codesign reports: valid on disk satisfies its Designated Requirement The expected Developer ID authority chain and TeamIdentifier are present. However, after some time, without modifying the bundle or executable, the exact same Quick Look extension starts failing verification for both architectures: invalid signature (code or signature have been modified) codesign -d then reports: Authority=(unavailable) Info.plist=not bound The executable SHA-256, size, and mtime remain unchanged. I also copied the now-invalid extension to a different directory, creating completely new inodes. The copy remains invalid. I verified that: all regular files in the original and copy are byte-for-byte identical executable SHA-256 is identical _CodeSignature/CodeResources is identical there are no hard links (link count is 1) there are no extended attributes anywhere in the extension com.apple.provenance, com.apple.quarantine, and com.apple.FinderInfo are absent copying the bundle to a new inode does not restore signature validity The affected extension executable currently has: SHA-256: 3b36d1aca258a371311a9c94e93d10606edc184ea120dd252cf230a251c67243 CDHash arm64: 178ff5b7b2cedbed00ec6bc07536d168e22d9ba5 CDHash x86_64: ada914101f5b107704b78958520c904c4f022894 Signing environment Developer ID Team ID: XY2B8MLPV8 The Developer ID Application certificate is newly issued with a new RSA 2048-bit private key. I have also observed the following message in the Security log during signing: CSSMERR_CSP_INVALID_KEYATTR_MASK No new occurrence of that error is logged when subsequently verifying the already-invalid extension. Troubleshooting already performed I have: issued a completely new Developer ID Application certificate with a new RSA 2048-bit private key verified the certificate chain and code-signing policy successfully reproduced related Keychain/identity problems in a fresh macOS user account tested with a newly created independent Keychain tested in Safe Mode reinstalled macOS without erasing user data Before reinstalling macOS, even security find-identity -v -p codesigning eventually failed to recognize otherwise valid Developer ID identities. After reinstalling macOS, security find-identity -v -p codesigning correctly reports all identities again. I then performed a durability test using the new Developer ID identity on a minimal Universal Mach-O binary. Verification succeeded: immediately after signing after approximately 2 minutes after approximately 5 minutes after copying the binary to a different directory The minimal binary remained valid throughout. However, the problem subsequently reproduced with the actual Quick Look extension. Notarization The application was packaged in a Developer ID Installer-signed PKG and submitted to Apple Notary Service. The submission was Accepted, stapling and validation succeeded, and Gatekeeper accepted the notarized PKG. Notarization submission ID: 54dc0de7-5089-4b8c-9c10-b5a74df8df97 I initially suspected the packaging process, but I subsequently found that the original pre-PKG Quick Look extension itself had become invalid. Therefore, this does not appear to be caused by PKG creation or extraction. Questions What could cause a Developer ID signature that initially verifies successfully to become invalid later when the signed files themselves have not changed? Is there a Security.framework / codesign diagnostic that can show exactly which part of the CMS signature or CodeDirectory validation is failing? Are there any known macOS 26.x issues involving code-signing validation or CSSMERR_CSP_INVALID_KEYATTR_MASK that could explain this behavior? I would be happy to collect additional Security logs, codesign diagnostics, or a sysdiagnose if that would help identify the cause.

My Individual Developer account (Team ID: SU8NVE3Z6C) has been suspended due to an automated compliance check regarding digital assets, citing Sections 14.8(a) and 2.8 of the DPLA. I have a clean 13-year track record on the App Store. On September 23, immediately after receiving the automated notice, I submitted all requested documentary evidence directly to provider_review. I provided my official residence documents and description of my apps. They do not involve custody, exchange, trading, or transmission of digital assets, nor do they violate any applicable laws. It has now been over a week since I submitted the full documentation. My entire portfolio of apps remains removed from the App Store. This prolonged downtime is causing severe ongoing financial loss and severely disrupting the experience for my active subscribers. Could an Apple Community Specialist or a senior support engineer please help escalate this review? I have provided everything asked of me and urgently need my account access restored. Thank you in advance for your assistance.

I'm submitting a new version of my app, and after click "submit for Review", it show that: A few more items are needed in order to submit for review The items listed below are required for submission:There are still screenshot uploads in progress. I didn't met this problem before. Is that mean I haven't upload all the screenshot required or it's still uploading the screenshots to App Store Connect's server? Cause before there is a "save" button after you drag images to the screenshots area, now you don't. And I think I have uploaded all the screenshots needed and I waited a day to try submit again, still the same. What should I do?

We are seeing a production crash that only affects devices reporting iOS 27.0.0. Devices on 27.0.1 and later, and on iOS 26, are unaffected. The app is built with Xcode 27.0 (the same binary shape appears with the Xcode 27.1 RC toolchain), deployment target iOS 26.0. The crashing code is a plain availability-gated call: extension View { @ViewBuilder func disableNavigationBarMinimization() -> some View { if #available(iOS 27.0, *) { toolbarMinimizationBehavior(.never, for: .navigationBar) } else { self } } } Crash report excerpt (addresses and app symbols removed): crash_info_entry_0: Failed to look up symbolic reference at <addr> - offset <n> - symbol <nearest stripped symbol> in <app binary> - pointer at <addr> is likely a reference to a missing weak symbol Crashed: com.apple.main-thread 0 libsystem_kernel.dylib __pthread_kill 2 libsystem_c.dylib abort 3 libswiftCore.dylib <redacted> 9 libswiftCore.dylib swift_getTypeByMangledName + 908 10 libswiftCore.dylib swift_getTypeByMangledNameInContext2 + 248 11 <app> __swift_instantiateConcreteTypeFromMangledNameV2 12 <app> specialized closure #1 in View.disableNavigationBarMinimization() 13 <app> closure #1 in SomeView.body.getter What we established: Because the deployment target is 26.0 and the API is @available(iOS 27.0, *), the app weak-imports both the function and its opaque result type descriptor. dyld_info -imports on the binary shows: _$s7SwiftUI4ViewPAAE27toolbarMinimizationBehavior_3forQrAA07ToolbareF0V_AA0H9PlacementVdtF [weak-import] (from SwiftUI) _$s7SwiftUI4ViewPAAE27toolbarMinimizationBehavior_3forQrAA07ToolbareF0V_AA0H9PlacementVdtFQOMQ [weak-import] (from SwiftUI) The call site has to instantiate the opaque return type's metadata before calling the function. That is the frame that aborts. So when dyld binds the descriptor to null, #available(iOS 27.0, *) passes and the process still dies. The symbol is present and exported on the iOS 27.0 build we can inspect locally (24A437, via Xcode's DeviceSupport symbols), and the same code runs fine on the iOS 27.0 simulator runtime (24A434). We cannot reproduce the crash on any device we own. The SwiftUI binary in 24A437 exports both toolbarMinimizeBehavior(_:for:) / ToolbarMinimizeBehavior and toolbarMinimizationBehavior(_:for:) / ToolbarMinimizationBehavior. The iOS 27.1 SDK only declares the latter, still annotated @available(iOS 27.0, *). This looks like a rename late in the 27.0 cycle. Our working theory is that some iOS 27.0.0 builds in the field (earlier 27.0 builds, possibly the ones preinstalled on new devices) predate the rename and only contain toolbarMinimizeBehavior, so the renamed symbol is absent and the weak import resolves to null. Questions: Is the @available(iOS 27.0, *) annotation on toolbarMinimizationBehavior(_:for:) accurate for every shipped 27.0.0 build? Should it be 27.0.1 or 27.1? Is there a supported way to guard against a missing opaque type descriptor at runtime, short of raising the availability check? Feedback filed as FB25095054.

I've never had anything but trouble with xcappdata, but I got what I wanted working in the previous xcode version, I could specify the xcappdata in my testplan and it would work on the simulators. Now, on XCode 27, the xcappdata doesn't load. I look in the xcode 27 release notes and see there is indeed an issue with xcappdata, and a workaround. Workaround: To make a .xcappdata bundle for use in Xcode’s Run scheme action do the following. Add .xcappdata to the folder created by Device Hub when downloading app data containers. Inside that folder make a new folder named AppData. Move the other content in that folder into AppData. For example, com.example.MyApp/{Documents,Library,tmp} becomes: com.example.MyApp.xcappdata/AppData/{Documents,Library,tmp} This is completely unhelpful. When am I downloading app data containers? What folder is created by Device Hub? Where is it? How does this apply to my testplan? What if I have multiple xcappdata bundles for different test plans? It looks to me like this workaround would be part of a script where at some magic moment I inject my app data into a simulator. Which might not be too bad So if I wanted to build this script it I imagine it looks like create a simulator install the app on the simulator find the folder related to the simulator copy in my xcappdata? Then I can run my tests?

I downloaded the CarPlay Simulator from Additional Tools for Xcode 27, but I can't find a way to test the navigation banners on the left or right side Several users have complained, and one of them finally sent me a photo. It looks fine in my simulator but not on their CarPlay screen How do we test those edge cases scenarios? This is my Simulator, looks fine And this is user's photo clearly showing the navigation banners in a different position

Hi there, My app uses UIScreen.screens.count (deprecated) to predict whether mirroring is happening on older iOS devices I noticed that the number of screens is different between iOS 26 SDK apps, and iOS 27 SDK apps. Can I expect that iOS 26 SDK apps will continue to return 1 screen like below for the iPhone Duo release?. I assume it's like this is to maximise compatibility. App built with SDK 26 on Xcode 27.1b1 iPhone Duo sim: UIScreen.screens.count == 1 App built with SDK 27 on Xcode 27.1b1 iPhone Duo sim: UIScreen.screens.count == 2 Thanks for the help! Sam

Hello, What is the supported revocation-status source or documented validation procedure for the following exact intermediate certificate, encountered in signatures on Apple-supplied Command Line Tools Python 3.9? This concerns first-party Apple code signing, not Developer ID, public TLS, or S/MIME. Certificate details Subject: CN=Apple Code Signing Certification Authority, OU=Apple Certification Authority, O=Apple Inc., C=US Serial: 0x21 (33 decimal) DER SHA-256: 5bdab1288fc16892fef50c658db54f1e2e19cf8f71cc55f77de2b95e051e2562 Validity: 2011-10-24 17:39:41 UTC to 2026-10-24 17:39:41 UTC Issuer: Apple Root CA Issuer DER SHA-256: b0b1730ecbc7ff4505142c49f1295e6eda6bcaed7e2c68c5be91b5a11001f024 Embedded CRL distribution point: http://www.apple.com/appleca/root.crl This intermediate has no Authority Information Access extension. Retained observations from 1 October 2026 At approximately 16:59 UTC, one request to: https://www.apple.com/appleca/root.crl recorded HTTP 200 and returned a 511-byte CRL with: thisUpdate: 2025-03-10 21:28:16 UTC nextUpdate: 2025-07-23 21:28:16 UTC SHA-256: 02b300d7e2edc09a33c0e98c0291da47932320761f6060ea8d7624f6e344f1dd At approximately 20:02 UTC, a separate request to: https://crl.apple.com/root.crl recorded HTTP 404 and returned a 287-byte HTML error body. This was an alternative HTTPS candidate; it does not establish the behavior of its HTTP counterpart. Neither request followed redirects or retried. Response bodies and normalized collector records were retained, but raw HTTP headers and stderr were not retained. These are limited observations from that date, not a claim about global service availability or key compromise. Questions Which current Apple-published source provides signed revocation-status evidence covering this exact intermediate? If the distribution point has moved, what is the authoritative replacement and how is its scope established? Which CP/CPS or documented first-party validation mechanism applies to this certificate? In particular, does Apple Certificate Policy v7.0 (20 March 2026), sections 2.1 and 4.10, cover this chain? If a public revocation-status service is no longer supported for this legacy first-party CA, what documented verification approach should be used, or which Apple team handles this question? I am not treating an expired CRL or an HTTP error as evidence that the certificate is revoked. I am also not assuming that a standalone CRL lookup reproduces macOS trust evaluation. I am asking for the supported source and verification procedure, not for a way to bypass validation, change trust settings, or re-sign Apple binaries. Thank you.

I am diagnosing a trust failure for an archived iOS arm64 app, without changing trust settings or rebuilding speculatively. Environment: macOS 26.6.2 (25G83), Xcode 27.0 (27A266a), as reported by installed public metadata. The diagnostic is a non-interactive Python helper calling the installed Security/CoreFoundation APIs through a bounded child-process runner in a desktop coding-agent session. This is not an Xcode GUI operation; an effect of the session, keychain/cache, or service access has not been established. Observed results: The app's embedded code CMS supplies three certificates. One explicitly identified signer matches the stored signer receipt in memory. The helper places the signer first, followed by the other supplied certificates. It uses SecPolicyCreateWithProperties(kSecPolicyAppleCodeSigning), SecTrustCreateWithCertificates, and SecTrustSetNetworkFetchAllowed(false). The status-returning setup calls succeed. Disabling intermediate fetching does not prove that all OS revocation/cache/network activity is absent. One SecTrustEvaluateWithError call returns false. The top-level CFError and its single kCFErrorUnderlyingErrorKey child both report NSOSStatusErrorDomain / -26276. The child has no further underlying-error key. This designated key chain was collected completely; other userInfo and localized descriptions were not collected. A prior recorded evaluation returned a chain containing only the signer. The latest diagnostic did not request another evaluated chain. Supplied certificates and the evaluated/trusted chain are distinct observations. Separate metadata collection found three distinct supplied certificates within their validity intervals at the observation time. Issuer/subject names matched signer → supplied issuer → third certificate, and the third had equal issuer/subject names. This does not verify issuer signatures, CA purpose, or root trust. Existing independent codesign --verify --deep --strict verification exits 1 with CSSMERR_TP_NOT_TRUSTED for arm64; it does not identify the failing certificate. The extraction/trust helper does not validate the CMS/CodeDirectory signature. The public SecTrust header allows false both for denied trust and for an evaluation that cannot complete. The inspected installed SecBase header defines errSecInternalComponent as -2070 and errSecDecode as -26275; it provided no name for -26276. I am not treating -26276 as either code or as proof of certificate/profile damage, sandbox denial, or trust-service failure. Questions: What supported interpretation or specific conditions explain -26276 on this public Code Signing API path, including the underlying error repeating the same domain/code? What smallest independent public field or observation distinguishes policy rejection from evaluation failure while keeping the policy, intermediate-fetch=false, and trust settings unchanged? The underlying key chain supplies no more specific code. How should this be interpreted alongside CSSMERR_TP_NOT_TRUSTED from strict verification of an archived iOS app? What specific evidence separates an embedded-signature/signing-input defect from a local trust or evaluation-context failure and justifies a targeted correction? No certificate names, fingerprints, DER, profile identifiers, account details, private paths, raw payloads, or attachments are included.

Overview We are investigating repeated "login" Keychain prompts affecting our macOS application on macOS 26.6.x. The issue appears after upgrading an existing installation. A clean uninstall/reinstall of the same version resolves it. Changing the affected Keychain item's Access Control from "Confirm before allowing access" to explicitly allowing our application/process also stops the prompts. On one affected machine, Apple Support observed a securityd crash followed by: SecKeyCreateSignature failed CSSMERR_DL_INVALID_DB_HANDLE Our code uses some legacy SecKeychain* APIs, so we are currently investigating whether this is related. Questions Were there any changes in macOS 26.6.x around securityd, Keychain ACL handling, or legacy SecKeychain* APIs that could explain this? Could an existing Keychain ACL become stale after an application upgrade, even when both versions are signed with the same Developer ID?

I wrote a python script MXSymbolicate to symbolicate crash reports produced by MetricKit. To symbolicate a given frame, it needs the symbol file for that frame's library. For system libraries, my system only has the requisite files on disk if I've plugged an iOS device of that type at that iOS version into my computer at some point (I assume these symbol files from the device are generated by Xcode when it's preparing to debug on a new device). All these different versions of the symbol files take up a fair bit of space on my machine over time, and it means the symbolication process isn't very portable. Is there a better way to get ahold of symbol files for system libraries? Or is the expectation that we (as third party developers) only symbolicate the frames from our own apps?

Environment: Apple silicon host, macOS 15.6 (24G84). An arm64 command-line launcher is ad hoc signed; strict signature verification passes and its only entitlement is com.apple.security.virtualization. An Apple macOS 15.6 restore image reported a supported hardware model. The VM configuration validated with 4 vCPUs, 8 GiB RAM, a fresh macOS auxiliary store, a 64 GiB writable raw disk, and a separate read-only raw disk. No guest networking, directory sharing, or socket device was configured. One observed sequence: Load the restore image, select its supported hardware model, create the auxiliary store and disk, validate the VM configuration, then call VZMacOSInstaller.install(completionHandler:). The Apple installation service starts; its logs reach RestoreOS and show a signing-server response. The host logs also record the service's sandbox denial and repeated CSSM permission errors: Sandbox: com.apple.Virtualization.Install deny(1) network-outbound /private/var/run/systemkeychaincheck.socket Can not connect to /var/run/systemkeychaincheck.socket: Operation not permitted CSSM Exception: 100001 UNIX[Operation not permitted] RestoreOS mode device connected AMAuthInstallRequestSendSyncWithHeader: received tss response The guest disk gained GPT/APFS volumes and roughly 17.6 GB of data. After about 11 minutes without a completion callback, the operator stopped the launcher. Exit status 130 reflects that interruption, not a result from VZMacOSInstaller. This launcher did not observe VZMacOSInstaller.progress. No VM retry has been performed since the incident. The socket and its host launchd service were present; a host-only connection succeeded outside the command sandbox. The denial was recorded against Apple's installation XPC service, and restore activity continued after it. Restore-image support, initial VM configuration/attachment construction, and launcher signature verification succeeded. A later restore or storage problem has not been ruled out. XPC sandbox socket denial is proven; cause of provisioning non-completion remains unproven. There is no terminal installer result from this attempt. Questions for anyone familiar with this installation path: Can denial of the installation service's connection to /var/run/systemkeychaincheck.socket prevent VZMacOSInstaller from completing? Are repeated CSSM Exception: 100001 UNIX[Operation not permitted] messages expected or incidental here, or can they be fatal? Without a completion callback before manual interruption, which supported progress signals or diagnostics distinguish slow valid progress, a stall, and a failure that did not surface through the callback? Is an ad hoc signed arm64 launcher with only com.apple.security.virtualization sufficient when Virtualization APIs initialize and the configuration validates? Is there any documented additional requirement for signing identity, entitlement, hardened runtime, installation-service access, host security, restore-image compatibility, auxiliary storage, or VM hardware configuration in this path? I am seeking interpretation of this one interrupted attempt, not asserting a framework defect or a cause for the non-completion.

Spent a good while debugging my own alarm code before working out the problem wasn't mine, so here it is in case someone's about to do the same thing. iOS 27 simulator, erased, clean install. requestAuthorization() comes back .denied and you never get a permission dialog at all. I had XCUITest sitting there watching SpringBoard for an Allow button over a bunch of runs, nothing. You can grant it manually in Settings and then authorizationState says .authorized, so the permission itself works, it's just the prompt that doesn't happen. On my actual phone (13, same 27.0) everything's normal, it schedules and rings and the alert comes up with snooze and stop on it. Then I went back to a 26.3 sim to compare and that one's worse here. SpringBoard keeps crashing, every few minutes, same thing each time: -[TLAlertQueuePlayerController _prepareAudioEnvironmentForStateDescriptor:isForMusicPlayback:] Unrecognised selector, SIGABRT, while it's trying to play the alert tone. It did that on a device I'd just erased with my app not even installed yet. Has anyone got the AlarmKit prompt to show up on 27 at all? Flag, particular device, entitlement, something in the plist I'm missing? And if you did grant it by hand there, do alarms actually fire afterwards on the sim? I never got far enough to find out, I just moved to the phone. Also curious whether anyone else sees that ToneLibrary crash on 26.3 under macOS 27. The AlarmKit wrapper I was poking at when I hit this is a free MIT gist, auth handling and deterministic alarm ids and the cancel-then-schedule ordering that got me earlier in the week: https://gist.github.com/yakubmurcek/61d8e3a60eb81e2c1f785010b4aa46de

Our app supports large-file uploads (20 GB+) and uploads of many files. We use a background URLSession so transfers can continue if the user backgrounds the app. In separate affected-device captures, Console logs and a sysdiagnose show dasd declining upload activities under Energy Budget Policy or Data Budget Policy. Upload tasks are created and resumed, but no bytes are transferred. Subsequent uploads can also remain queued, including after earlier uploads are cancelled and the app is relaunched. The issue is intermittent but can persist: one device recovered after approximately 24 hours; another remained affected for several days. We have not established what causes recovery or how the relevant budget eligibility is computed or replenished. Foreground and power observations For the energy-budget reproduction, the user kept the app foregrounded. Application lifecycle logs and RunningBoard running-active-Visible notifications corroborate foreground/active state around the affected task creation and resume operations. The rejection repeatedly reports: Energy Budget Policy [energyBudget]: Required:1.00, Observed:0.00 Decision: MNP Battery samples were approximately 68%, with Low Power Mode off. New uploads using the same session succeeded while the device was connected to external power and were rejected again after disconnection. Discretionary configuration versus daemon classification Our upload-session factory does not set isDiscretionary to true. In a separate, successful reproduction, instrumentation read isDiscretionary from the actual owning URLSession.configuration at task creation: 10:35:04.234749-0500 Frame.io: Upload task 1 created in session com.frameio.backgroundSession.diagnostics, configured isDiscretionary: false The corresponding daemon entry was: 10:35:04.245137-0500 nsurlsessiond: NDSession <8BA476D9-E790-46B6-B1DA-0246E14BBDAF> Task <1B16494D-BBE8-448F-9297-9DB8772ADD92>.<1> current discretionary status for com.frame.FrameIO is discretionary (opt-in: 0) All five tasks in that successful upload showed this combination. We do not yet have the instrumented configuration readout from the failed energy-budget reproduction. Implementation notes Large files are split into smaller files to support resumable uploads through our backend API. Each part is submitted as a file-backed upload task through the same background session, using a stable session identifier across launches. Goal User-initiated uploads make progress while the app is foregrounded and the network is available, and continue when possible after backgrounding. We understand background execution is system-controlled, but need to avoid uploads remaining stalled for days with no actionable recovery. We are considering switching between foreground and background URLsessions when the app moves between the foreground and background, but have concerns about that the bookkeeping on that path could be a brittle pattern. We have also considered using a BGContinuedProcessingTaskRequest for the entire upload, but have concerns about running into new scheduling issues there. Questions What session configuration and task-submission pattern does Apple recommend for this requirement? Is a background URLSession appropriate for both foreground and background uploading, or should we use a different architecture? Is it expected that tasks created and resumed while the app is foreground/active, with the owning session reporting isDiscretionary = false, can be blocked by Energy Budget or Data Budget Policy? If so, what supported approach allows these user-initiated uploads to progress while the app remains foregrounded? When this restriction persists across cancellation, new uploads, and app relaunch, what supported recovery mechanism should we implement? Can the app detect the restriction and take an effective action, rather than requiring external power or waiting an unknown amount of time? For 20 GB+ files and large upload batches split into file-backed tasks, are there recommended chunk sizes, outstanding-task limits, or session-management practices that prevent this failure mode? If the captured foreground behavior is unexpected, is this a known OS issue with an available fix or supported workaround? What additional evidence is needed to obtain a concrete remediation?

For an existing iOS generic-password Keychain item, what documented public API or query contract can establish that its returned SecAccessControl has no additional authentication, application-password, or operation-specific constraints? The item must remain WhenUnlockedThisDeviceOnly, in an exact access group and identity, and non-synchronizing. An unknown or unverified item must be refused without modifying, deleting, or replacing it. An attribute-only creation with no explicit access-control object can return a SecAccessControl when data and attributes are read. We observed this on an iOS 26.5 Simulator. The returned object compared different from a freshly created zero-flags object. We are not treating either that comparison or a successful no-UI read as proof of its complete constraints. The public interface we reviewed exposes creation and type identification; constraint inspection and serialization appear in private headers. Evaluating one operation also does not describe the item's complete policy. Is there a supported discriminator we have missed? If not, is there a documented creation-provenance and persistent-item-identity contract that establishes this property across relaunch, and what limitations apply to existing or recreated items? Please clarify the supported contract rather than private implementation details. We need to preserve refusal of unverified existing items while using the public Keychain APIs correctly.

I'm looking for clarification on the supported lifecycle semantics of VZVirtualMachine on macOS. Suppose process A creates and starts a VZVirtualMachine. While that VM is running, process A unexpectedly terminates or crashes. What is the supported behavior of that same original running VM instance? Is the VM automatically stopped or terminated when its owning process exits or crashes? If the VM can continue running, is there a supported API for a newly started process B to reconnect to or obtain control of that same already-running VM instance? If process B can reacquire the original VM, can it then force noncooperative termination of that instance, equivalent to using stop(completionHandler:) while the original controlling object still exists? Is there a supported way for process B to determine authoritatively that the original VM has stopped after process A is gone? Are there relevant differences between normal process exit, an unexpected crash, and forced process termination? I'm specifically asking about the same original running VM instance. Creating a new VZVirtualMachine with the same configuration, or restoring previously saved machine state, would not answer the question. If the owner-loss behavior is intentionally unspecified, or if there is no supported mechanism for another process to reacquire the same running VM, that would also answer the question. I'm interested in the supported Virtualization.framework contract rather than experimentally observed behavior. Environment: macOS 26.5.1 on Apple Silicon.

Team JHNW3WU9NQ (Individual). Every submission is rejected with statusCode 7000 and issues null, the newest on 2026-10-06 (submission 4ab80a9a-2dae-437e-a3f1-52a33751d3c0). Developer Support case 102939827032 has been open since 2026-08-17; the identity verification Apple requested was accepted; the case has been with engineering since, with no update since 2026-09-15. Agreements are accepted, the Developer ID Application certificate is valid, and the build is signed with the hardened runtime. Several other threads report the same status for 5 days to 5+ weeks. Has anyone had a team configured after a case of this age, and what finally worked? An Apple engineer, please pick this up: the status text itself sends us to Developer Programs Support, who have not resolved it.

I have an App Store version stuck In Review. I need to cancel / remove it from review so I can submit a newer build. I contacted Apple Developer Support. They said they cannot manually remove the app from review and that I have to cancel it myself. I have tried everything on my side: App Store Connect web UI → Remove this version from review / Cancel Submission App Store Connect on iPhone App Store Connect API (canceled: true on the review submission, and removing the submission item) Every attempt fails. In the UI I get errors like “An error has occurred. Try again later” / “Your changes could not be saved. Try again later.” Via the API I get HTTP 409 STATE_ERROR.ENTITY_STATE_INVALID (“Resource cannot be canceled at the moment, please try again later” / “Cannot remove item because of state of reviewSubmission”). The version stays In Review. I’ve reproduced this in Chrome and Safari, and on the phone app, plus the API so it doesn’t seem like a browser-only issue. Has anyone gotten past this when Support says you must cancel it yourself but Connect won’t let you? Any workaround, or is waiting for Apple the only option?