JitsiMeet.Maui 1.0.0-preview.11

Jitsi Meet MAUI

A .NET MAUI plugin that integrates the Jitsi Meet video-conferencing SDK on both Android and iOS through native binding libraries. This project demonstrates how to create C# bindings for a complex native SDK and consume them from a cross-platform .NET MAUI app.

📦 This plugin is available as a NuGet package! You can install it directly from NuGet without cloning this repository:

dotnet add package JitsiMeet.Maui --prerelease

👉 https://www.nuget.org/packages/JitsiMeet.Maui/1.0.0-preview.10

Requirements

Demo

https://github.com/user-attachments/assets/b41704c2-5dcc-449f-961c-21511526fa05

Table of Contents

• Project Structure
• How the Binding Works
  • Android Binding
  • iOS Binding
• Native Binaries
  • Android Dependencies
  • iOS Frameworks
• Demo App
  • Architecture
  • Android Implementation
  • iOS Implementation
• Deep Linking & Authentication
  • How meet.jit.si Authentication Works
  • Android Setup
  • iOS Setup
• Getting Started
• What You Can Customise
• Versions & Upgrading
• Troubleshooting
• License

Project Structure

JitsiMeetMAUI/
├── JitsiMeetMAUI.sln # Solution file (3 projects)
│
├── JitsiMeet.Android.Binding/ # Android binding library
│ ├── JitsiMeet.Android.Binding.csproj
│ └── Transforms/
│ ├── Metadata.xml # Java → C# type fixes
│ ├── EnumFields.xml
│ └── EnumMethods.xml
│
├── JitsiMeet.iOS.Binding/ # iOS binding library
│ ├── JitsiMeet.iOS.Binding.csproj
│ ├── ApiDefinition.cs # Objective-C → C# API surface
│ └── Structs.cs # Native enums (RecordingMode, etc.)
│
├── JitsiMeetDemo/ # .NET MAUI demo app
│ ├── IJitsiMeetService.cs # Cross-platform service interface
│ ├── MainPage.xaml / .cs # UI & join logic
│ ├── MauiProgram.cs # DI registration
│ └── Platforms/
│ ├── Android/
│ │ ├── AndroidJitsiMeetService.cs # Android IJitsiMeetService
│ │ ├── MauiJitsiMeetActivity.cs # Hosts Jitsi view + deep link handling
│ │ └── AndroidManifest.xml # Permissions
│ └── iOS/
│ ├── AppDelegate.cs # Handles auth redirect URL scheme
│ ├── IOSJitsiMeetService.cs # iOS IJitsiMeetService
│ └── Info.plist # URL scheme registration
│
├── NativeBinaries/ # Pre-downloaded native SDK files
│ ├── android/
│ │ ├── jitsi-meet-sdk-12.0.0.aar # Main Jitsi Android SDK
│ │ └── deps/ # ~30 transitive AAR/JAR deps
│ └── ios/
│ ├── JitsiMeetSDK.xcframework
│ ├── hermes.xcframework
│ ├── WebRTC.xcframework
│ └── GiphyUISDK.xcframework
│
└── pad_icons.py # Utility script for icon padding

How the Binding Works

Android Binding

The Android binding project (JitsiMeet.Android.Binding) turns the native Java/Kotlin Jitsi Meet SDK AAR into a C# library that .NET MAUI can reference.

1. The .csproj — JitsiMeet.Android.Binding.csproj

<TargetFramework>net9.0-android</TargetFramework>


<AndroidClassParser>class-parse</AndroidClassParser>
<AndroidCodegenTarget>XAJavaInterop1</AndroidCodegenTarget>


<MSBuildWarningsAsMessages>XA4241;XA4236;XA4242</MSBuildWarningsAsMessages>

Key points:

The main AAR reference:

<AndroidLibrary Include="..\NativeBinaries\android\jitsi-meet-sdk-12.0.0.aar" />

NuGet packages provide the AndroidX and Google Play dependencies that the SDK expects at runtime:

• Xamarin.AndroidX.AppCompat
• Xamarin.AndroidX.Fragment
• Xamarin.AndroidX.LocalBroadcastManager
• Xamarin.AndroidX.Media3.ExoPlayer (+ Dash, HLS, SmoothStreaming, UI)
• Xamarin.AndroidX.SwipeRefreshLayout
• GoogleGson
• Xamarin.GooglePlayServices.Auth

2. Metadata Transforms — Transforms/Metadata.xml

When the Java→C# code generator runs, sometimes the auto-generated return types are wrong. The Metadata.xml file fixes them:

<metadata>
 
 <attr path="/api/package[@name='org.jitsi.meet.sdk']/class[@name='JitsiInitializer']/method[@name='create' and count(parameter)=1 and parameter[1][@type='android.content.Context']]"
 name="managedReturn">Java.Lang.Object</attr>
</metadata>

This specific fix changes the generated C# return type of JitsiInitializer.create(Context) to Java.Lang.Object, because the auto-generator incorrectly inferred a more specific type.

Tip: If you encounter build errors about incorrect types after updating the SDK version, Metadata.xml is where you fix them. You can inspect the AAR contents by renaming it to .zip, extracting classes.jar, and opening it in a decompiler like www.decompiler.com to see the actual Java signatures.

iOS Binding

The iOS binding project (JitsiMeet.iOS.Binding) wraps the native Objective-C JitsiMeetSDK.xcframework into a C# library.

1. The .csproj — JitsiMeet.iOS.Binding.csproj

<TargetFramework>net9.0-ios</TargetFramework>
<IsBindingProject>true</IsBindingProject>
<AllowUnsafeBlocks>true</AllowUnsafeBlocks>

Native framework references:

<NativeReference Include="..\NativeBinaries\ios\JitsiMeetSDK.xcframework">
 <Kind>Framework</Kind>
 <ForceLoad>True</ForceLoad>
</NativeReference>
<NativeReference Include="..\NativeBinaries\ios\hermes.xcframework">
 <Kind>Framework</Kind>
 <ForceLoad>True</ForceLoad>
</NativeReference>
<NativeReference Include="..\NativeBinaries\ios\WebRTC.xcframework">
 <Kind>Framework</Kind>
 <ForceLoad>True</ForceLoad>
</NativeReference>
<NativeReference Include="..\NativeBinaries\ios\GiphyUISDK.xcframework">
 <Kind>Framework</Kind>
 <ForceLoad>True</ForceLoad>
</NativeReference>

ForceLoad = True ensures all symbols are linked, which is necessary for React Native's runtime class lookups.

Note: Although we are only binding JitsiMeetSDK, the WebRTC.xcframework, hermes.xcframework, and GiphyUISDK.xcframework must also be included as native references. The Jitsi Meet SDK depends on these at runtime — without them, the app will crash with missing symbol errors at launch.

2. API Definition — ApiDefinition.cs

This is the heart of the iOS binding. Every Objective-C class/protocol you want to use from C# must be declared here. The file binds 6 key types:

Example — binding the JitsiMeetView class:

[BaseType(typeof(UIView))]
interface JitsiMeetView
{
 [NullAllowed, Export("delegate", ArgumentSemantic.Weak)]
 NSObject Delegate { get; set; }

 [Export("join:")]
 void Join([NullAllowed] JitsiMeetConferenceOptions options);

 [Export("leave")]
 void Leave();

 [Export("hangUp")]
 void HangUp();

 // ... more methods
}

3. Structs & Enums — Structs.cs

Native enums used by the SDK are declared here:

[Native]
public enum RecordingMode : long { File, Stream }

[Native]
public enum WebRTCLoggingSeverity : long { Verbose, Info, Warning, Error, None }

Tip: To generate ApiDefinition.cs from scratch, you can use the Objective Sharpie tool on the .xcframework headers, then manually clean up the output.

Native Binaries

Android Dependencies

The Jitsi Meet Android SDK (v12.0.0) has ~30 transitive React Native dependencies that must be present at runtime. These are not NuGet packages — they are raw .aar / .jar files hosted in Jitsi's own Maven repository.

Downloading Dependencies with Gradle

The easiest way to resolve and download all transitive dependencies is to use Microsoft's Xamarin Gradle Dependency script. This is the same approach documented in the maui-native-sdk-bindings guide (see Step 3: Identify and Add All Transitive Dependencies).

1. Create a minimal Android Studio project with an Android Library module. Place the Jitsi AAR in a libs/ folder and reference it in the module's build.gradle.
2. Apply Microsoft's Gradle script by adding this line to the module's build.gradle:

   apply from: 'https://raw.githubusercontent.com/xamarin/XamarinComponents/main/Util/AndroidGradleDependencyInfo.gradle'
   

3. Run the task:

   ./gradlew :{ModuleName}:xamarin
   

   This automatically resolves all transitive dependencies, copies the AAR/JAR files into a xamarin/ folder, and prints the full list of Maven coordinates.
4. Copy the resolved files from the xamarin/ folder into NativeBinaries/android/deps/.

Tip: If you have issues with Gradle 9.0, use the modified Gradle script instead.

All resolved files land in NativeBinaries/android/deps/ and are referenced by the demo app's .csproj:

<AndroidAarLibrary Include="..\NativeBinaries\android\deps\*.aar" />
<AndroidJavaLibrary Include="..\NativeBinaries\android\deps\*.jar" />

Handling AAR Naming Conflicts

Sometimes two AARs contain the same Java package, causing the build to fail. To fix this, rename the conflicting .aar file to .zip — this excludes it from linking while keeping it around for reference. Repeat the build until it succeeds.

iOS Frameworks

The iOS side uses pre-built .xcframework bundles placed in NativeBinaries/ios/. All four frameworks are required — the Jitsi Meet SDK depends on the others at runtime, and the app will crash without them:

These are downloaded from the official Jitsi Meet iOS SDK releases.

Demo App

Architecture

The demo app uses a dependency injection pattern to abstract platform-specific Jitsi implementations behind a shared interface.

IJitsiMeetService ← Shared interface
├── AndroidJitsiMeetService ← Android implementation
└── IOSJitsiMeetService ← iOS implementation

Registration in MauiProgram.cs:

#if ANDROID
 builder.Services.AddSingleton<IJitsiMeetService, AndroidJitsiMeetService>();
#elif IOS
 builder.Services.AddSingleton<IJitsiMeetService, IOSJitsiMeetService>();
#endif

builder.Services.AddTransient<MainPage>();

The MainPage receives the service via constructor injection and calls JoinMeeting() when the user taps the button.

Android Implementation

On Android, joining a meeting requires launching a separate Activity (MauiJitsiMeetActivity) because the Jitsi SDK takes over the full screen with its own React Native view hierarchy.

Flow:

1. AndroidJitsiMeetService.JoinMeeting() sets global default options, then starts MauiJitsiMeetActivity via an Intent with the room name, display name, and email as extras.
2. MauiJitsiMeetActivity.OnCreate() creates a JitsiMeetView, builds JitsiMeetConferenceOptions, calls _view.Join(options), and sets the view as content.
3. A BroadcastReceiver listens for CONFERENCE_TERMINATED and READY_TO_CLOSE actions to automatically finish the activity.
4. The activity implements IJitsiMeetActivityInterface and overrides permission methods to ensure camera/mic access works.

Required Android permissions in AndroidManifest.xml:

<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.RECORD_AUDIO" />
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_CAMERA" />
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_MICROPHONE" />

Important: The demo app sets <EmbedAssembliesIntoApk>true</EmbedAssembliesIntoApk> in the csproj to disable Fast Deployment. This is required — without it, AndroidX Startup throws missing DEX class exceptions at runtime.

iOS Implementation

On iOS, the IOSJitsiMeetService creates a JitsiMeetView, wraps it in a UIViewController, and presents it modally over the current MAUI page.

Flow:

1. IOSJitsiMeetService.JoinMeeting() builds conference options using the builder pattern (JitsiMeetConferenceOptions.FromBuilder).
2. A JitsiMeetView is created and set as the root view of a new UIViewController.
3. The view controller is presented full-screen.
4. A CustomJitsiDelegate (subclass of JitsiMeetViewDelegate) listens for ConferenceTerminated and ReadyToClose to dismiss the view controller and clean up.

Deep Linking & Authentication

The public meet.jit.si server requires authentication (Google/GitHub) to create rooms. The SDK handles this by opening the sign-in page in the device's browser. After the user authenticates, the browser redirects back to the app using a custom URL scheme, passing a JWT token that grants moderator/admin rights.

How meet.jit.si Authentication Works

The authentication flow follows these steps:

1. User taps "Join" in the app
2. SDK connects to meet.jit.si → server requires auth
3. SDK opens browser to the Firebase sign-in page
4. User signs in with Google or GitHub
5. Sign-in page constructs a redirect URL with JWT token:
 - Android: intent://meet.jit.si/Room#jwt=TOKEN#Intent;scheme=org.jitsi.meet;package=org.jitsi.meet;end
 - iOS: org.jitsi.meet://meet.jit.si/Room#jwt=TOKEN
6. Browser redirects → app catches the URL → re-joins conference with JWT
7. User enters the meeting as moderator/admin

Important: The disableDeepLinking config override should be set to true in your conference options. This prevents the SDK's web layer from showing a "How do you want to join?" page, while still allowing the authentication redirect to work.

Android Setup

1. App Identifier

The meet.jit.si auth page hardcodes package=org.jitsi.meet in the Android intent redirect. This means the redirect will only be delivered to an app with that exact package name. For development/demo purposes, set your ApplicationId to org.jitsi.meet:

<ApplicationId>org.jitsi.meet</ApplicationId>

⚠️ You must uninstall the official Jitsi Meet app from your device first — Android doesn't allow two apps with the same package name. Remember to change this back to your own identifier before publishing.

If you use a self-hosted Jitsi server, you can configure the auth redirect to use your own package name and skip this step entirely.

2. Intent Filters on MauiJitsiMeetActivity

The activity must declare intent filters to handle the org.jitsi.meet:// scheme and https://meet.jit.si deep links:

[IntentFilter(
 new[] { global::Android.Content.Intent.ActionView },
 Categories = new[] { global::Android.Content.Intent.CategoryDefault,
 global::Android.Content.Intent.CategoryBrowsable },
 DataScheme = "org.jitsi.meet")]
[IntentFilter(
 new[] { global::Android.Content.Intent.ActionView },
 Categories = new[] { global::Android.Content.Intent.CategoryDefault,
 global::Android.Content.Intent.CategoryBrowsable },
 DataScheme = "https",
 DataHost = "meet.jit.si")]
public class MauiJitsiMeetActivity : AppCompatActivity, IJitsiMeetActivityInterface

3. Handle Deep Links in OnCreate and OnNewIntent

OnCreate must detect whether the activity was launched from a deep link (browser) or from within the app:

// In OnCreate:
if (intent?.Action == Intent.ActionView && intent.Data != null)
{
 // Launched from browser deep link — use the full URL (includes JWT)
 options = new JitsiMeetConferenceOptions.Builder()
 .SetRoom(intent.Data.ToString())
 .SetConfigOverride("disableDeepLinking", true)
 .Build();
}
else
{
 // Normal launch from within the app
 // ... use JitsiRoom/JitsiName/JitsiEmail extras
}

OnNewIntent handles the auth redirect when the activity is already running:

protected override void OnNewIntent(Intent? intent)
{
 base.OnNewIntent(intent);
 if (intent?.Action == Intent.ActionView && intent.Data != null)
 {
 var options = new JitsiMeetConferenceOptions.Builder()
 .SetRoom(intent.Data.ToString())
 .Build();
 _view.Join(options);
 return;
 }
 JitsiMeetActivityDelegate.OnNewIntent(intent);
}

iOS Setup

1. Register URL Scheme in Info.plist

<key>CFBundleURLTypes</key>
<array>
 <dict>
 <key>CFBundleURLName</key>
 <string>org.jitsi.meet</string>
 <key>CFBundleURLSchemes</key>
 <array>
 <string>org.jitsi.meet</string>
 </array>
 </dict>
</array>

Note: Unlike Android, iOS URL schemes are per-app — there's no package name constraint. Your Bundle Identifier does not need to be org.jitsi.meet.

2. Handle the URL in AppDelegate

[Export("application:openURL:options:")]
public override bool OpenUrl(UIApplication application, NSUrl url, NSDictionary options)
{
 if (url.Scheme == "org.jitsi.meet")
 {
 var service = IPlatformApplication.Current?.Services.GetService<IJitsiMeetService>();
 if (service is IOSJitsiMeetService iosService)
 {
 iosService.JoinWithAuthUrl(url);
 return true;
 }
 }
 return base.OpenUrl(application, url, options);
}

3. JoinWithAuthUrl in IOSJitsiMeetService

This method handles both re-joining an existing conference (auth redirect) and launching fresh from a browser deep link:

public void JoinWithAuthUrl(NSUrl url)
{
 var options = JitsiMeetConferenceOptions.FromBuilder(builder =>
 {
 builder.Room = url.AbsoluteString;
 builder.SetConfigOverride("disableDeepLinking", true);
 });

 if (_jitsiMeetView != null)
 {
 // Re-join existing conference with JWT
 MainThread.BeginInvokeOnMainThread(() => _jitsiMeetView.Join(options));
 return;
 }

 // Create view and present from scratch
 MainThread.BeginInvokeOnMainThread(() =>
 {
 _jitsiMeetView = new JitsiMeetView { /* ... */ };
 // ... present and join
 });
}

Getting Started

Prerequisites

• .NET 9 SDK
• Visual Studio 2022 (17.12+) or JetBrains Rider with .NET MAUI workload
• For Android: Android SDK with API 26+ (configured via dotnet workload install maui-android)
• For iOS: Xcode 15+ on macOS (configured via dotnet workload install maui-ios)

Steps

1. Clone the repository

   git clone https://github.com/ihassantariq/JitsiMeet-Maui.git
   cd JitsiMeet-Maui
   

2. Download Android dependencies (if the NativeBinaries/android/deps/ folder is empty) Use the Gradle-based approach described in the Android Dependencies section to resolve and download all transitive dependencies.

3. Build and run

   # Android
   dotnet build JitsiMeetDemo/JitsiMeetDemo.csproj -f net9.0-android
   
   # iOS
   dotnet build JitsiMeetDemo/JitsiMeetDemo.csproj -f net9.0-ios
   

4. If the Android build fails with AAR naming conflicts, rename the conflicting .aar to .zip and rebuild. See Handling AAR Naming Conflicts for details.

What You Can Customise

🔗 Server URL

By default, the app connects to the public https://meet.jit.si server. To use your own self-hosted Jitsi server, change the URL in:

• Android: AndroidJitsiMeetService.cs (line 17) and MauiJitsiMeetActivity.cs (line 78)
• iOS: IOSJitsiMeetService.cs (line 25)

// Change from:
new Java.Net.URL("https://meet.jit.si")
// To:
new Java.Net.URL("https://your-jitsi-server.com")

🎛️ Feature Flags

Enable or disable meeting features via the builder:

.SetFeatureFlag("chat.enabled", true) // In-meeting chat
.SetFeatureFlag("invite.enabled", true) // Invite button
.SetFeatureFlag("prejoinpage.enabled", true) // Pre-join lobby screen
.SetFeatureFlag("welcomepage.enabled", false) // Jitsi welcome/home page
.SetFeatureFlag("recording.enabled", false) // Meeting recording
.SetFeatureFlag("pip.enabled", true) // Picture-in-picture (Android)

👤 User Info

Pass authenticated user details:

var userInfo = new JitsiMeetUserInfo();
userInfo.DisplayName = "John Doe";
userInfo.Email = "john@example.com";
// userInfo.Avatar = new NSUrl("https://..."); // iOS only

🎨 App Branding

• App icon: Replace Resources/AppIcon/appiconfg.png
• Splash screen: Replace Resources/Splash/splash.png
• Logo on main page: Replace Resources/Images/logo.png
• App ID: Change <ApplicationId> in JitsiMeetDemo.csproj

🔐 JWT Authentication

If your Jitsi server requires JWT tokens:

// Android (in MauiJitsiMeetActivity.cs):
.SetToken("your-jwt-token")

// iOS (in IOSJitsiMeetService.cs):
builder.Token = "your-jwt-token";

Versions & Upgrading

Current Versions

This project is pinned to the following versions:

Upgrading to a Newer Jitsi Meet SDK Version

When a new version of the Jitsi Meet SDK is released, here is what you need to do for each platform:

Android Upgrade Steps

1. Download the new AAR

   • Go to the Jitsi Maven Repository and find the new version.
   • Download the .aar file and place it in NativeBinaries/android/, replacing the old one.
   • Update the AAR filename reference in JitsiMeet.Android.Binding.csproj:

     
     <AndroidLibrary Include="..\NativeBinaries\android\jitsi-meet-sdk-NEW_VERSION.aar" />
     

2. Update transitive dependencies

   • Check the new SDK's pom.xml in the Jitsi Maven repo to see if dependency versions have changed.
   • Delete the contents of NativeBinaries/android/deps/ and re-resolve using the Gradle-based approach described in Android Dependencies.

3. Fix binding errors

   • Try building the binding project:

     dotnet build JitsiMeet.Android.Binding/JitsiMeet.Android.Binding.csproj
     

   • If the build fails with type errors, update Transforms/Metadata.xml to fix the new type mismatches. Inspect the new AAR by renaming it to .zip, extracting classes.jar, and viewing it in www.decompiler.com.

4. Update NuGet packages

   • If the new SDK depends on newer AndroidX or Google Play Services versions, update the <PackageReference> versions in JitsiMeet.Android.Binding.csproj.

5. Resolve AAR conflicts

   • Run the demo build. If it fails with naming conflicts, rename the conflicting .aar to .zip and rebuild.

iOS Upgrade Steps

1. Download new xcframeworks

   • Go to jitsi-meet-ios-sdk-releases and download the new version's xcframeworks.
   • Replace the contents of NativeBinaries/ios/ with the new frameworks (JitsiMeetSDK.xcframework, hermes.xcframework, WebRTC.xcframework, GiphyUISDK.xcframework).

2. Regenerate ApiDefinition.cs (if the API surface changed)

   • Use Objective Sharpie to generate a new definition from the framework headers:

     sharpie bind -framework NativeBinaries/ios/JitsiMeetSDK.xcframework/ios-arm64/JitsiMeetSDK.framework -sdk iphoneos
     

   • Compare the output with the existing ApiDefinition.cs and merge in any new methods, properties, or classes.
   • Update Structs.cs if new enums were added.

3. Build and test

   dotnet build JitsiMeet.iOS.Binding/JitsiMeet.iOS.Binding.csproj
   dotnet build JitsiMeetDemo/JitsiMeetDemo.csproj -f net9.0-ios
   

Upgrading .NET Version (e.g. .NET 9 → .NET 10)

1. Update <TargetFramework> in all three .csproj files (e.g. net9.0-android → net10.0-android).
2. Update the MAUI workload:

   dotnet workload update
   

3. Check if NuGet package versions (AndroidX, Google Play Services) have newer releases compatible with the new .NET version and update accordingly.
4. Rebuild and test both platforms.

Troubleshooting

License

This project is provided as a sample/demo. The Jitsi Meet SDK is licensed under the Apache 2.0 License.