Move drops, share previews, and layered Apple icons

Drag and drop can now Move

A drop target can now ask for a Move instead of a Copy.

A drop target is the view that receives a dragged item, and in .NET MAUI you make one by adding a DropGestureRecognizer to a view.

Why it was added

A drop target could only answer None or Copy. None blocks the drop, and Copy makes iOS and Windows present the dragged item as a copy. That is the wrong message when the user is moving something and not duplicating it.

A developer asked for a Move answer back in 2023, in issue #16472. Until now the only way to get one on Apple devices was to write Apple-only code.

What you get

One shared line asks for a Move: set AcceptedOperation to DataPackageOperation.Move. On iOS and Mac Catalyst the system is then told that the drag is a move, so it stops presenting it as a copy.

A typical use

Picture a board with two lists, "To do" and "Done". The user drags a task from one list to the other, and the task should leave the first list. That is a move, and now the drop target can say so. Your app still does the actual moving of the task in its own drop handler.

How it works

1. The user drags an item over a drop target.
2. Your DragOver handler sets e.AcceptedOperation = DataPackageOperation.Move.
3. On iOS and Mac Catalyst, DragAndDropDelegate asks every drop recognizer on the view and combines their answers.
4. It then picks one result to propose to the system, as the diagram shows.

Did every recognizer answer None?

yes

Drop rejected

no

Did your app set its own native drop proposal?

yes

That proposal is used

no

Does any answer include Copy?

yes

Copy

no

Does the drag session allow a Move?

yes

Move

no

Drop rejected

Copy wins a tie on purpose, so if one recognizer says Copy and another says Move, the drop is a Copy.

Try it

The drop target asks for a Move in its DragOver handler.

void OnDragOver(object? sender, DragEventArgs e)
{
    e.AcceptedOperation = DataPackageOperation.Move;
}

On Windows the drag source also has to allow it, which the sample page does in DragStarting.

#if WINDOWS
using WinOp = Windows.ApplicationModel.DataTransfer.DataPackageOperation;
#endif

void OnDragStarting(object? sender, DragStartingEventArgs e)
{
#if WINDOWS
    e.PlatformArgs!.DragStartingEventArgs.AllowedOperations =
        WinOp.Copy | WinOp.Move;
    e.PlatformArgs.Handled = true;
#endif
}

Where the code lives

Controls owns this. The new value is in DataPackageOperation, you set it through DragEventArgs, and the Apple logic sits in DragAndDropDelegate.

Current limit

Sources

Gerald Versluis, in pull request #39016: Add opt-in Move support to drag and drop

A preview image for shared text and links

ShareTextRequest has a new property, PreviewImage.

The share sheet is the system dialog that lists the apps you can share to, and it can now show an image of your choice next to the text or link.

Why it was added

Share.RequestAsync could share text or a link, but there was no way to hand over a picture. The share sheet showed a bare address and a generic icon.

Both iOS and Android can show a richer preview. An app that wanted one had to stop using the Share API and write its own code for each platform. Issue #38824 asked to close that gap.

What you get

One new property. Set it, and the share sheet shows your picture next to the title, much like Safari does when you share a web page. You keep using the shared Share API on every platform.

A typical use

Your app shares a link to something that has a picture, such as a user profile, a product or a place. The person sharing sees that picture in the share sheet and not only a web address.

How it works

1. Create a ShareTextRequest with text or a link.
2. Set PreviewImage to a ShareFile, which is a pointer to a file on the device.
3. Pass the request to Share.RequestAsync.
4. What happens next depends on the platform.

ShareTextRequestText or UriTitlePreviewImage

iOS and Mac Catalyst

The image goes into the link details, as both the picture and the icon.

Android 10 and later

The image rides along with the share request, and the share sheet gets read access to it. Title becomes the preview title.

Older Android and other platforms

PreviewImage is ignored. Sharing works as before.

The sample app tries it with a screenshot: it captures the screen, saves it as a PNG and shares that file as the preview.

Try it

await Share.RequestAsync(new ShareTextRequest
{
    Uri = "https://example.com",
    Title = "Example",
    PreviewImage = new ShareFile(imagePath)
});

Here imagePath is the full path to an image file on the device.

Where the code lives

Essentials owns this. The property is declared in Share.shared.cs, the Android code is in Share.android.cs and the Apple code is in Share.ios.cs.

Current limit

Sources

Ed Giardina, in pull request #38825: Add ShareTextRequest.PreviewImage for share sheet previews

Icon Composer icons for iOS and Mac Catalyst

A MauiIcon can now point to an Icon Composer .icon folder.

Icon Composer is Apple's tool for designing layered app icons, and it saves each icon as a folder whose name ends in .icon. MauiIcon is the project item that names your app icon.

Why it was added

Apple introduced the .icon format with its Liquid Glass design in macOS 26. An app icon in this format is no longer one flat picture. It is a set of layers with effects such as translucency and lighting.

MauiIcon only took a single image, usually SVG or PNG, which Resizetizer resized for each platform. That route cannot carry layers. The .NET tooling for Apple platforms learned to compile .icon folders in dotnet/macios #24722, and this change connects MauiIcon to it.

What you get

Your iOS and Mac Catalyst app can ship the layered icon exactly as it was designed, with no flat export in between. Apple's asset compiler builds the icon, the other platforms keep their SVG or PNG, and there is no new project item to learn.

A typical use

A designer builds the app icon in Icon Composer and hands you a folder called AppIcon.icon. You add the folder to the project, point MauiIcon at it for the Apple targets, and build.

How it works

1. Add a MauiIcon that points to the .icon folder. Use a condition to limit it to iOS and Mac Catalyst.
2. Keep your SVG or PNG MauiIcon for the other platforms.
3. During the build, a new step called _CollectMauiNativeAppleIcon notices the .icon ending.
4. It checks the folder. There must be an icon.json file at the top and at least one file in Assets.
5. From there the icon takes its own route through the build, shown below.

MauiIconWhat does it point to?

An SVG or PNG file

The route that already existed.

Resizetizer resizes the image

Icons in the sizes each platform needs

An .icon folder

New. iOS and Mac Catalyst only.

Resizetizer leaves the icon alone

Every file in the folder goes to the Apple build as an image asset

AppIcon is set to the folder name

Apple's asset compiler builds the app icon

The step also saves a hash of each file in the folder. A hash is a short code that changes when the file changes, so an edited icon gets compiled again.

Try it

In the project file, swap the icon for the Apple targets only.

<ItemGroup Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'ios'
                   Or $([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'maccatalyst'">
  <MauiIcon Remove="Resources\AppIcon\appicon.svg" />
  <MauiIcon Include="Resources\AppIcon\AppIcon.icon" />
</ItemGroup>

The Remove and Include lines follow the integration test in the pull request. The condition is the usual way a .NET MAUI project limits items to one platform, and the folder name is only an example.

Where the code lives

Resizetizer owns this. All the new steps are in Microsoft.Maui.Resizetizer.After.targets.

Current limit

Sources

Gerald Versluis, in pull request #38958: Resizetizer: Support Icon Composer MauiIcon bundles