Mac CLI publish iOS app: change in where Xcode stores mobile provisioning files

[baskren]

As of version 16, Xcode changed the location of where it stores mobile provisioning files:

BEFORE 16.0: ~/Libraries/MobileDevice/Provisioning Profiles
AFTER 16.0: ~/Libraries/Developer/Xcode/UserData/Provisioning Profiles.

If you manually provision your apps, this is a problem. For example, in my app's *.cproj, I have the following (anonymized):

  <!-- APP SIGNING -->
  <Choose>
    <!-- APPLE IOS -->
    <When Condition=" $(IsIOS)">
      <PropertyGroup>
        <CodesignEntitlements>Platforms\iOS\Entitlements.plist</CodesignEntitlements>
        <ProvisioningType>manual</ProvisioningType>
      </PropertyGroup>
      <PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
        <!-- APP STORE -->
        <CodesignKey>Apple Distribution: XXXXX (XXXXXXXXX)</CodesignKey>
        <CodesignProvision>APP STORE XXXXX</CodesignProvision>
      </PropertyGroup>
    </When>

 ...

Currently, dotnet build publish -f net8.0-ios -c Release is going to look for the APP STORE XXXXX provisioning profile in my ~/Libraries/MobileDevice/Provisioning Profiles folder. However, this is a new provisioning profile - SO XCODE DIDN'T PUT IT THERE. And, to add insult to injury, if Xcode is running AND I manually copy the provisioning profile to ~/Libraries/MobileDevice/Provisioning Profiles, Xcode immediately deletes it!

A work around is to be sure Xcode is closed when I copy my new provisioning profile to ~/Libraries/MobileDevice/Provisioning Profiles. However, it would be great if there was a way to enable msbuild to work with the new mobile provisioning profiles store.

I don't know if the part of the build chain is owned by Microsoft or UNO so my question is where would be the best place to raise awareness of this?

Thank you for your consideration!

[baskren]

OK, Ignore this. Turns out everything above is true EXCEPT that msbuild already works just fine with this new location. I'm just an idiot!

[jeromelaban]

Thanks for the update! No worries. In all cases, though, this particular part of the build is coming from .NET Workloads, so if changes need to be made it would have needed to come from there.

[baskren]

Thanks, @jeromelaban