[azure devops] AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Assert: platformExpert, value: 0

[jeromelaban]

Description

When starting the iOS simulators on macos-15, the following assertion happens:

AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Assert: platformExpert,  value: 0
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Failed to get AppleVirtualPlatformARMPE service.

The message shows up as stdout, "polluting" machine readable outputs like simctl.

This is azure devops specific, this does not happen on github actions with macos-15.

Related to #10918

Platforms affected

• Azure DevOps
• GitHub Actions - Standard Runners
• GitHub Actions - Larger Runners

Runner images affected

• Ubuntu 20.04
• Ubuntu 22.04
• Ubuntu 24.04
• macOS 12
• macOS 13
• macOS 13 Arm64
• macOS 14
• macOS 14 Arm64
• macOS 15
• macOS 15 Arm64
• Windows Server 2019
• Windows Server 2022

Image version and build link

20241106.316

Is it regression?

Not for this image, but compared to other images, yes.

Expected behavior

No assertions in the log

Actual behavior

Many messages like this one:

AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Assert: platformExpert,  value: 0
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Failed to get AppleVirtualPlatformARMPE service.

Repro steps

Run the following pipeline:

pool:
  vmImage: 'windows-2022'

trigger:
  - main

stages:
- stage: Setup
  jobs:
  - job: Pipeline_Validations

    pool:
      vmImage: 'macos-15'

    steps:
    - checkout: self
      clean: 'true'
      fetchDepth: 0

    - bash: |
        /bin/bash -c "sudo xcode-select -s /Applications/Xcode_16.app/Contents/Developer"
  
        echo "Listing iOS simulators"
        xcrun simctl list devices --json
  
        export SIMULATOR_VERSION="com.apple.CoreSimulator.SimRuntime.iOS-18-1"
        export SIMULATOR_NAME="iPad Pro 13-inch (M4)"
  
        export UITEST_IOSDEVICE_ID=`xcrun simctl list -j | jq -r --arg sim "$SIMULATOR_VERSION" --arg name "$SIMULATOR_NAME" '.devices[$sim] | .[] | select(.name==$name) | .udid'`
        xcrun simctl boot $UITEST_IOSDEVICE_ID
  
        sleep 300
      name: Run

[susmitamane]

@jeromelaban We will look into the issue and keep you posted with updates.

[topi-identio]

We noticed the same issue happening in our e2e pipeline starting yesterday with macOS-15 as well. It happens with both iOS 18.0 and 18.1 Simulators.

[albertoAround]

Same problem here. Any news? It's kinda blocking

[examplecodecn]

+1

[sureshe456]

Hi All, We are still investigating the issue. Will keep you posted with updates soon.

[sanket492]

Observed this issue today and all our build and automation pipelines are failing. @sureshe456 @susmitamane please fix this issue.

[albertoAround]

Is there an ETA? We're in serious troubles and we're starting to consider rolling back to physical device for building @sureshe456 @susmitamane

[sureshe456]

Hi All, We are still checking on it. will be posted any updates.

[sureshe456]

Hi @jeromelaban,
Based on the analysis, the macos-15-large (macos-15) is based on an AMD64 processor, while the macos-15-xlarge (macos-15-arm64) is based on an ARM64 processor. The AppleVirtualPlatformARMPE service is specifically designed for Apple Silicon (ARM-based) processors, such as the M1, M1 Pro, M1 Max, M2, and later chips. It is not compatible with AMD64 (x86_64) processors.
Therefore, when you start iOS simulators on macos-15 (AMD64 processor), then AppleVirtualPlatformARMPE service will be inaccessible. However, this service will be accessible on the macos-15-xlarge (macos-15-arm64) image.

[albertoAround]

So what kind of image do we have to type? I tried macos-15-arm64 and macos-15-xlarge but I received for both the same error

"No config name or imagelabel provided in request" @sureshe456

[sureshe456]

For macOS 15 Arm64: Please try with this macos-15.
FYI...

[albertoAround]

We're working on Azure hosted images. So here are the ones that we can pick https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml

There is no macos-15-large or xlarge. @sureshe456

[jeromelaban]

Therefore, when you start iOS simulators on macos-15 (AMD64 processor), then AppleVirtualPlatformARMPE service will be inaccessible. However, this service will be accessible on the macos-15-xlarge (macos-15-arm64) image.

This could make sense, however, even selecting iPad (10th generation) does not work.

Also, regardless of the selected emulator, even running xcrun simctl list devices --json will emit the messages.

Furthermore, as noted by others in the thread, the images you mention are not on azure devops, only GHA.

[topi-identio]

The Simulators worked fine the day before this issue was posted. What changed? Did something update?

[albertoAround]

I mean, it's two weeks that we can't build... From such a large company it's almost unbelievable and we are paying for this service.

[sureshe456]

Hi All, We apologize for the inconvenience and understand the frustration this has caused. There was an issue with patches update on macOS 15 image generation.So, our team is actively working on resolving the issue, and we appreciate your patience during this time. Thank you for bringing this to our attention. We will keep you updated with any new information.Thanks.

[wimdows-nl]

Exactly same problem here, but getting this on Azure DevOps, after XCode 16 was removed from MacOS 15 build agents, and we had to specify MacOS 15 instead to use XCode 16.

AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Assert: platformExpert,  value: 0
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Failed to get AppleVirtualPlatformARMPE service.
** ARCHIVE FAILED **

Seems an issue for all Mac OS 15 image flavours, including 15.1 and 15.0.1.

[hakonk]

I'm also getting multiple errors like this:

AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Assert: platformExpert,  value: 0
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Failed to get AppleVirtualPlatformARMPE service.

with an Azure DevOps hosted MacOS agent running:

Operating System
macOS
15.0.1
24A348
Runner Image
Image: macos-15
Version: 20241022.244

I'm getting this for archive and export, i.e., not when targeting a simulator:

/usr/bin/xcodebuild \
    -workspace ./App.xcworkspace \
    -scheme AppScheme \
    -sdk iphoneos \
    -configuration Release \
    clean archive

xcodebuild -exportArchive \
  -archivePath path/to/archive \
  -exportPath path/to/export \
  -exportOptionsPlist path/to/options.plist

If there is any workaround, please provide an explanation here! Needless to say, this renders our pipelines completely useless.

[albertoAround]

Almost a month and still not fixed and not an ETA.

[hakonk]

@sureshe456 is there an ETA for the fix here?

[hakonk]

It turns out that, on my end, I had another unrelated error that went under the guise of the error messages:

AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Assert: platformExpert,  value: 0
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Failed to get AppleVirtualPlatformARMPE service.

After fixing this error my pipeline is able to run. Since I am only using hosted agents for archiving and exporting, I passed -destination "generic/platform=iOS" \ upon clean archive to remove warnings about devices. This does work in my pipeline:

/usr/bin/xcodebuild \
    -workspace path/to/workspace \
    -scheme AppScheme \
    -sdk iphoneos \
    -archivePath path/to/archive \
    -configuration Release \
    -destination "generic/platform=iOS" \
    clean archive

[sureshe456]

Hi All, We are still working on resolving the issue. Will keep you posted with any update.

[wimdows-nl]

Hi All, We are still working on resolving the issue. Will keep you posted with any update.

Thanks - can you confirm this will also be addressed for the Azure DevOps build agents?

[albertoAround]

Any news? @sureshe456

[Suniket]

Is there any update @sureshe456 ?

[sureshe456]

Hi All, We are still investigating the issue. Will keep you posted on any updates.Thanks for your patience.

[topi-identio]

Related to this issue Xcode 16 was re-added to the macOS-14 images #10703 (comment), so we reverted our pipeline to use that for now.

[NorseGaud]

@topi-identio @albertoAround @wimdows-nl @sanket492 I'm a bit confused about this. What problem does this log output cause? I'm not seeing any actual failures even with these logs showing up. Please clarify what is actually failing. #10925 (comment) for example noticed they had another error unrelated to these messages.

[tkhho]

For us this is an issue too. It causes that linting of a cocoapod artefact fails as it tries to detect which simulator is available:

    - ERROR | [iOS] unknown: Encountered an unknown error (unexpected token at 'AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Assert: platformExpert,  value: 0
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Failed to get AppleVirtualPlatformARMPE service.
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Assert: platformExpert,  value: 0
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Failed to get AppleVirtualPlatformARMPE service.
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Assert: platformExpert,  value: 0
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Failed to get AppleVirtualPlatformARMPE service.
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Assert: platformExpert,  value: 0
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Failed to get AppleVirtualPlatformARMPE service.
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Assert: platformExpert,  value: 0
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Failed to get AppleVirtualPlatformARMPE service.
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Assert: platformExpert,  value: 0
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Failed to get AppleVirtualPlatformARMPE service.
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Assert: platformExpert,  value: 0
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Failed to get AppleVirtualPlatformARMPE service.
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Assert: platformExpert,  value: 0
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Failed to get AppleVirtualPlatformARMPE service.
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Assert: platformExpert,  value: 0
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Failed to get AppleVirtualPlatformARMPE service.
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Assert: platformExpert,  value: 0
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Failed to get AppleVirtualPlatformARMPE service.
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Assert: platformExpert,  value: 0
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Failed to get AppleVirtualPlatformARMPE service.
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Assert: platformExpert,  value: 0
AVPIdentity: AppleVirtualPlatformHostKey.mm:234: Failed to get AppleVirtualPlatformARMPE service.
'

[NorseGaud]

@tkhho , so the issue is that a linting stage is trying to use some sort of output? Can you clarify a bit more about what exactly it's failing to do and what you're running to reproduce it?

[tkhho]

We are building a iOS Framework, which is distributed via Cocoapods. As final step bundle exec pod lib lint is called. This steps uses the framework and links it against test apps, to detect build issues. This is more testing, than linting. This tests have to run against iOS Simulators and it uses simctl to detect installed iOS simulator. Because of this error message, it is not able to and fails.

https://guides.cocoapods.org/making/using-pod-lib-create.html#deploying-your-library

[NorseGaud]

it uses simctl to detect installed iOS simulator

As far as my testing shows, it doesn't cause a failure but outputs text instead of JSON. Does the tool choke when parsing the JSON output because of those log lines? It might be a way to change our code to remove non-json text.

[tkhho]

Does the tool choke when parsing the JSON output because of those log lines?
"Choke" might not be the right term. The output is no longer valid JSON, so it becomes unreadable.

That said, I may have misunderstood your perspective. You are probably not a Microsoft employee tasked with addressing the root cause but rather an individual developer trying to find a workaround.

[NorseGaud]

That said, I may have misunderstood your perspective.

I am not an individual developer, nor am I trying to find a workaround. I'm trying to understand why the bug, which seems to be from one from Apple's libraries, outputs extra text and is causing failures when the commands themselves doesn't throw a non-zero exit code. Thank you for the information as it was actually helpful.

[topi-identio]

@topi-identio @albertoAround @wimdows-nl @sanket492 I'm a bit confused about this. What problem does this log output cause? I'm not seeing any actual failures even with these logs showing up. Please clarify what is actually failing. #10925 (comment) for example noticed they had another error unrelated to these messages.

For us the issue is that we can't run our e2e test pipeline using the macOS-15 image. We run Detox tests for our React Native app with the Simulator, which started failing when this issue appeared. The app build succeeds but the tests don't run due to issues with the Simulator.

[NorseGaud]

Thanks @topi-identio what issues though? Do the tests fail to parse the json like other users are reporting? Or is the simulator itself broken?

[NorseGaud]

Opened Apple Feedback to report this: FB16084148
Forum post has been submitted and I'll kindly ask that everyone go boost it: https://forums.developer.apple.com/forums/thread/770509

[kober32]

Another month passed - any update on this @sureshe456 pls?

We're migrating from the AppCenter to Azure Pipelines and downgrading to a macos-14 runner feels wrong as the only working solution...

[NorseGaud]

Hi @kober32 , this is a bug with Apple. I recommend reaching out to Apple and putting pressure on them to fix.

[kober32]

@NorseGaud Yeah, but it would be nice to have an option for arm-based runners for pipelines anyway.

I tried to downgrade to macos14 but without any luck so far (same error), kinda bummer since MSFT is closing AppCenter soon and telling users to switch to Azure Devops, which are not working ATM (for intended purpose) :(