Maui.MicrosoftClarity

Wrapper for Microsoft Clarity for mobile

Usage

Firstly register package installer in your MauiProgram.cs

 builder.Services.AddMicrosoftClarity();

then in App.xaml.cs inject IMicrosoftClarityService:

public partial class App : Application {
    private readonly IMicrosoftClarityService _microsoftClarityService;

    public App(IMicrosoftClarityService microsoftClarityService) {
        InitializeComponent();
        _microsoftClarityService = microsoftClarityService;
    }
}

and also override there method OnStart() to call _microsoftClarityService.Initialize with your project id.

protected override void OnStart() {
    _microsoftClarityService.Initialize("<MicrosoftClarityProjectIdHere>");

    base.OnStart();
}

⚠️ iOS Local debugging

Because of MAUI and VS bugs:

• dotnet/macios#19229
• https://developercommunity.visualstudio.com/t/MAUI---Cannot-create-native-types-when-d/10180586
• potential workaround: dotnet/maui#10800 (comment)

it is not possible to run your app with hot-restart(direct local iOS deploy from VS for Windows)

Dummy classes

So that you dont have to specify platform for this package and it's calls, also Windows and MacCatalyst are added with dummy implementations. When you call one of their methods you will always get:

• true for bool returns
• new List<> for collections
• string.Empty for string values

Exception behavior

• Library will throw exceptions only in case developer did some mistake
• in other cases, when there is some corrupted state it will return default value of that type.

Automated SDK updates

This repo runs a daily pipeline that watches Microsoft's Clarity Android and iOS SDKs and tries to bump + re-wire this package automatically. The flow:

flowchart TD
    A[Microsoft ships new Clarity SDK] --> B[06:00 UTC daily<br/>automatic-detect-sdk-updates.yml]
    B --> C[Bump PR opened<br/>label: auto-bump]
    C --> D[automatic-bump-and-wire.yml:<br/>build binding + diff API + build wrapper]

    D --> E{Outcome?}

    E -->|API unchanged<br/>wrapper compiles| F[Auto-merge as<br/>stable release]
    E -->|API additions<br/>or wrapper breaks| G[Label: needs-wiring<br/>Ping @copilot<br/>with API diff]
    E -->|Binding itself broken| H[Label: binding-broken<br/>Ping @copilot<br/>with binding-fix guide]

    G --> K[Agent commits wiring]
    H --> L{Agent can fix?}
    L -->|yes| K
    L -->|no| M[Agent adds label:<br/>needs-human]

    K --> N[Human review + merge]
    M --> N
    F --> O[main updated]
    N --> O

    O --> R[release-please<br/>maintains release PR<br/>for wrapper version]
    R --> S[Merge release PR<br/>tags vX.Y.Z]
    S --> T[Manually run<br/>publish-*.yml workflows]
    T --> U[NuGet.org]

    classDef happy fill:#d4edda,stroke:#155724,color:#000
    classDef warn fill:#fff3cd,stroke:#856404,color:#000
    classDef human fill:#f8d7da,stroke:#721c24,color:#000
    class F,O,U happy
    class G,H,K warn
    class M,N human

Loading

The only manual steps for you:

1. Review and merge agent wiring PRs when needs-wiring is applied
2. Fix binding-generator failures the agent escalates as needs-human (rare)
3. Trigger the three publish-*.yml workflows after each release tag

See .github/COPILOT_INSTRUCTIONS.md for the rules the agent follows.

Contributions

Feel free to create an issue or pull request. In case you would like to do massive changes in the package please firstly discuss them in the issue because otherwise there is high chance that such big PR would be rejected.

License

This repository is licensed with the MIT license.