Post

Replies

Boosts

Views

Activity

Native macOS App Attest returns production evidence from a development-signed build
I’m investigating App Attest sandbox configuration for a native macOS app. Apple DTS suggested asking here. Environment: Physical MacBook running macOS 27.0.1 (26A434) Xcode 27.0 (27A266a) Native SwiftUI macOS application, launched from Xcode in Debug Development signing with a regenerated Mac development provisioning profile The same App ID is used for the iPad and Mac targets Observed behavior: App Attest is enabled for the App ID in the Developer portal. The Mac entitlements source requests: com.apple.developer.devicecheck.appattest-environment = development We tried both a build-setting substitution and the literal development value, regenerated the profile, and rebuilt. The inspected Mac provisioning profile does not contain this entitlement. Xcode’s generated signing entitlements (.xcent) and the signed application also omit it. DCAppAttestService generates a fresh key and returns an attestation successfully. Our development server observes AAGUID 61707061747465737400000000000000 (production) and rejects it because it requires development evidence. The physical iPad development build produces development evidence and enrolls successfully against the same server. Relevant server diagnostic: client App Attest environment mismatch expected_environment=development observed_aaguid=61707061747465737400000000000000 The failure occurs at the environment gate, before certificate/signature verification. I am not claiming that the entire Mac attestation has already passed cryptographic verification. Questions: Is development/sandbox App Attest supported for native macOS 27 apps? If supported, which entitlement and provisioning configuration is required, and why is the requested environment omitted during signing? If production-mode evidence is expected for development-signed Mac apps, what is the recommended server environment policy? Is this a known issue with macOS 27.0.1 or Xcode 27.0? We would like to keep development attestation separate from production while retaining full cryptographic verification and using the same App ID for both platforms. I can provide sanitized entitlement and signing-output excerpts, together with a minimal reproducer. Which diagnostics would help establish why the development entitlement is missing?
0
0
18
9h
Native macOS App Attest returns production evidence from a development-signed build
I’m investigating App Attest sandbox configuration for a native macOS app. Apple DTS suggested asking here. Environment: Physical MacBook running macOS 27.0.1 (26A434) Xcode 27.0 (27A266a) Native SwiftUI macOS application, launched from Xcode in Debug Development signing with a regenerated Mac development provisioning profile The same App ID is used for the iPad and Mac targets Observed behavior: App Attest is enabled for the App ID in the Developer portal. The Mac entitlements source requests: com.apple.developer.devicecheck.appattest-environment = development We tried both a build-setting substitution and the literal development value, regenerated the profile, and rebuilt. The inspected Mac provisioning profile does not contain this entitlement. Xcode’s generated signing entitlements (.xcent) and the signed application also omit it. DCAppAttestService generates a fresh key and returns an attestation successfully. Our development server observes AAGUID 61707061747465737400000000000000 (production) and rejects it because it requires development evidence. The physical iPad development build produces development evidence and enrolls successfully against the same server. Relevant server diagnostic: client App Attest environment mismatch expected_environment=development observed_aaguid=61707061747465737400000000000000 The failure occurs at the environment gate, before certificate/signature verification. I am not claiming that the entire Mac attestation has already passed cryptographic verification. Questions: Is development/sandbox App Attest supported for native macOS 27 apps? If supported, which entitlement and provisioning configuration is required, and why is the requested environment omitted during signing? If production-mode evidence is expected for development-signed Mac apps, what is the recommended server environment policy? Is this a known issue with macOS 27.0.1 or Xcode 27.0? We would like to keep development attestation separate from production while retaining full cryptographic verification and using the same App ID for both platforms. I can provide sanitized entitlement and signing-output excerpts, together with a minimal reproducer. Which diagnostics would help establish why the development entitlement is missing?
Replies
0
Boosts
0
Views
18
Activity
9h