App Extension (.appex) builds correctly but is never copied into PlugIns/ during publish (net10.0-ios, IsAppExtension ProjectReference)

[conklinpr]

Environment

• .NET SDK: 10.0.400
• iOS workload: 26.5.10315/10.0.100
• Xcode: 26 (native macOS build, not Pair-to-Mac)
• Target: net10.0-ios, ios-arm64
• Container app: .NET MAUI (net10.0-ios)
• Extension type: Share Extension (NSExtensionPointIdentifier = com.apple.share-services)

Summary
A from a .NET MAUI iOS app to a net10.0-ios app-extension project compiles the extension into a real, valid .appex bundle — confirmed by extracting and inspecting it directly. But the built .appex is never copied into .app/PlugIns/ during dotnet build/dotnet publish, so the extension never appears in iOS's share sheet, and no error or warning is raised — the container app just builds and installs successfully without its extension.

Repro steps

1. Create a .NET MAUI app targeting net10.0-ios.
2. Add a second project targeting net10.0-ios with true (Share Extension NSExtension in Info.plist, NSExtensionPrincipalClass pointing at a UIViewController subclass).
3. Reference it from the container app: <ProjectReference Include="..\Extension\Extension.csproj" IsAppExtension="true" />.
4. dotnet build/dotnet publish -f net10.0-ios -c Release (or Debug) on macOS, natively (not via Pair-to-Mac from Windows — see "Ruled out" below).
5. Inspect the built .app: find <ContainerApp>.app/PlugIns — empty or missing, despite the extension project having built successfully.

What was ruled out (each independently tested, not assumed)

• Pair-to-Mac as the cause: initially suspected, and a related-but-different bug was found and fixed for it (_BuildReferencedExtensionProjects defaulting to false on Windows-hosted builds, fixed upstream in dotnet/macios#25805, confirmed present in this SDK version). But the PlugIns-copy issue reproduces identically on a fully native macOS build — installed the SDK + workloads directly on the Mac, built with dotnet build/dotnet publish locally, no Windows/Pair-to-Mac involved at all. Same result: clean build, .appex compiles, PlugIns/ stays empty.
• RID mismatch: the extension project's was previously pinned to simulator RIDs only from an earlier, unrelated fix — removed so it inherits the container's RID. No change in behavior.
• Build vs publish, Debug vs Release: tested all four combinations. No change.
• Stale incremental state: full clean (rm -rf bin obj on both projects) before each attempt. No change.
• Windows-style path separators in the ProjectReference Include: not the cause — same result with forward slashes.
• -p:IsMacEnabled=true: found this property in the SDK's own Xamarin.Shared.Sdk.targets as something that partially gates the PlugIns pipeline; forcing it explicitly made no difference.

What the SDK's own source suggests
Reading Xamarin.Shared.Sdk.targets directly in the installed SDK pack (Microsoft.iOS.Sdk.net10.0_26.5/26.5.10315/targets/) shows the PlugIns-publishing logic has two separate code paths — an uncompressed path (_PlugIns, _DirectoriesToPublish) and a compressed/zip-based fallback (_CompressedPlugIns, _DecompressPlugIns, _CollectDecompressedPlugIns) — with a comment in the targets file itself acknowledging this area has known incomplete handling. This reads as genuine, still-open fragility in the SDK's own extension-publishing pipeline rather than a project misconfiguration on our end, but we haven't yet traced exactly which target is failing to add the extension's output to ResolvedFileToPublish (or equivalent) — happy to help narrow this further if a maintainer can point at where that item should be getting added.

Impact
Blocks App Extensions entirely for .NET MAUI iOS apps referencing a sibling extension project the standard way — the extension silently never ships, with no build error to signal `why.```

[conklinpr]

Traced this further by grepping the installed SDK's own .targets files directly (Microsoft.iOS.Sdk.net10.0_26.5/26.5.10315). Two findings that narrow this down:

1. IsAppExtension is only ever consumed as an MSBuild property ($(IsAppExtension)), never as item metadata (%(IsAppExtension)). Every occurrence in Xamarin.Shared.Sdk.targets/.props governs the extension project's own build behavior when building itself (target platform inference, _CanOutputAppBundle, _FixRootAssemblyForAppExtensions, etc.). I can't find anywhere that reads the IsAppExtension="true" metadata set on the container app's element back out to decide how to classify that reference's resolved output. Those look like two disconnected mechanisms.

2. PublishFolderType="PlugIns" is only ever assigned in the decompressed/zip-extraction path (_DecompressedPlugIns, e.g. line 2478 of the version above), never for the regular/uncompressed case an app-extension ProjectReference actually produces. I checked this across every SDK version currently installed on this machine (net9.0 and net10.0, several patch versions) — same pattern in all of them.

Together, this suggests the actual bridge — "this ProjectReference is an app extension, therefore tag its resolved output PublishFolderType=PlugIns" — isn't implemented in the shipped .targets XML at all, and most likely lives in a compiled MSBuild task instead, which is out of reach from outside the source tree. If a maintainer can point at where that classification is supposed to happen (or confirm it's simply missing for the uncompressed path), that would let us either work around it correctly or confirm this is a real gap rather than a project misconfiguration.

Grep commands used, for reproducibility:

grep -n -A 40 "_PlugIns|_CompressedPlugIns|_CollectDecompressedPlugIns" "/usr/local/share/dotnet/packs/Microsoft.iOS.Sdk.net10.0_26.5/26.5.10315/targets/Xamarin.Shared.Sdk.targets"
grep -rn "IsAppExtension" /usr/local/share/dotnet/packs/Microsoft.iOS.Sdk.net10.0_26.5/26.5.10315/targets/ /usr/local/share/dotnet/packs/Microsoft.MacCatalyst.Sdk.net10.0_26.5/26.5.10315/targets/
grep -rn "PublishFolderType="" /usr/local/share/dotnet/packs/ /usr/local/share/dotnet/sdk/*/

[rolfbjarne]

Thanks for the detailed report and for the follow-up investigation.

I tried to reproduce this locally on macOS with the same iOS workload version you're using (26.5.10315/10.0.100), but so far I haven't been able to — in every combination I tried, the .appex ends up in <ContainerApp>.app/PlugIns/ as expected.

Here's what I tested:

Variation	Result
Plain iOS app container	PlugIns/MyExtension.appex ✅
.NET MAUI app container	PlugIns/MyExtension.appex ✅
dotnet build	✅
dotnet publish	✅ (also present inside the IPA)
Debug	✅
Release	✅
Simulator (iossimulator-arm64)	✅
Device (ios-arm64)	✅
Building the project directly	✅
Building the solution	✅
..\Ext\Ext.csproj (backslashes)	✅
../Ext/Ext.csproj (forward slashes)	✅

Setup used: dotnet new maui (and separately dotnet new ios) for the container app, dotnet new ios-notification-service-extension for the extension (IsAppExtension=true, OutputType=Library, the extension's ApplicationId being the container's bundle id + a suffix), referenced with:

<ProjectReference Include="..\MyExtension\MyExtension.csproj" IsAppExtension="true" />

Each run was done after a full rm -rf bin obj on both projects.

So there's something in your project setup that differs from mine, and I'd like to find out what. Could you provide a binary log of a failing build? That records exactly which targets ran and what items they produced, which should let me pinpoint where the extension drops out of the pipeline:

dotnet build -f net10.0-ios -c Debug /bl:build.binlog

(after rm -rf bin obj in both projects), then attach build.binlog here — you can zip it if GitHub rejects the extension.

Please note that a binlog can contain sensitive information (environment variables, file paths, and the contents of files embedded in the build). You can inspect it first with the MSBuild Structured Log Viewer, and if you'd rather not post it publicly, let me know and we can arrange another way to share it.

Alternatively, a minimal self-contained project that reproduces the problem would work just as well.

---

Also happy to answer your targets question: the copy into PlugIns/ isn't driven by PublishFolderType at all. It happens in tools/msbuild/Xamarin.Shared.targets (not targets/Xamarin.Shared.Sdk.targets, which is what you grepped) — _SeparateAppExtensionReferences reads the IsAppExtension metadata off ProjectReference, _ResolveAppExtensionReferences builds those projects and collects the resulting bundle paths, _PlaceAppExtensions tags them with ContainerName=PlugIns, and _CopyAppExtensionsToBundle does the copy. That's the chain the binlog would let us walk.

[dotnet-policy-service]

Hi @conklinpr. We have added the "need-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.