Smarter recommendations, built for quality

Designed around your needs

More voices and formats to explore

What's next

Shiny’s modules (background jobs, notifications, push, GPS and geofencing, BluetoothLE, HTTP transfers, data sync and the rest) have never really been about MAUI. Shiny.Core has its own platform layer: native directories, main thread, device and app info and lifecycle on every platform, with no MAUI dependency. What MAUI gave Shiny was a host: somewhere to build the container at the right moment and a way to receive the platform events Shiny needs.

Shiny 6.5.3 adds that host for two more UI frameworks:

A hosting package sounds like plumbing, but two of its jobs decide whether an app actually works.

1. Start Shiny when the OS starts the process, not when the UI appears. On Android, a background job, a push or a geofence can start your process with no activity at all. If Shiny’s container is only built when your first screen shows, the job never runs and the push is dropped.
2. Pass the platform events through. On Android that means permission results, activity results and new intents. Without them, every Shiny permission request waits forever and notification taps never reach your delegate.

MAUI does both through UseShiny() and its lifecycle events. Avalonia and Uno each get there differently.

Shiny.Hosting.Avalonia needs Avalonia 12 or later. AppBuilder.UseShiny(...) builds and runs the Shiny host after Avalonia sets up its platform services and before your Application is created, so Host.Current is ready in Initialize() and OnFrameworkInitializationCompleted(). Avalonia has no DI container of its own, so the container Shiny builds is the app’s container. Keep the registrations in one method every head calls:

public static class ShinyStartup
{
    public static void Configure(HostBuilder builder)
    {
        builder.Services.AddSingleton<MyService>();
        builder.Services.AddConnectivity();
#if PLATFORM
        builder.Services.AddNotifications<MyNotificationDelegate>();
#endif
    }
}

// desktop - Program.cs
public static AppBuilder BuildAvaloniaApp() => AppBuilder
    .Configure<App>()
    .UsePlatformDetect()
    .UseShiny(ShinyStartup.Configure);

On Android and iOS, you call it from CustomizeAppBuilder. Avalonia runs that from Application.OnCreate and didFinishLaunching, so Shiny is running when the OS starts the app in the background. On Android, ShinyAvaloniaMainActivity forwards the activity events:

[Application]
public class MainApplication : AvaloniaAndroidApplication<App>
{
    public MainApplication(IntPtr handle, JniHandleOwnership ownership) : base(handle, ownership) { }

    protected override AppBuilder CustomizeAppBuilder(AppBuilder builder)
        => base.CustomizeAppBuilder(builder).UseShiny(ShinyStartup.Configure);
}

[Activity(MainLauncher = true, LaunchMode = LaunchMode.SingleTop, Theme = "@style/Theme.AppCompat.DayNight.NoActionBar")]
public class MainActivity : ShinyAvaloniaMainActivity { }

Desktop heads target plain net10.0, so they get NetPlatform and the plain .NET version of each module, with Shiny’s main thread set to Avalonia’s Dispatcher.UIThread. On iOS, foreground and background changes and notification taps need no code. Push methods go on your own AvaloniaAppDelegate<TApp>, and only in an app that uses push. See Avalonia Hosting for the details.

Uno apps already have a container: Uno.Extensions.Hosting. Shiny.Hosting.Uno uses it instead of building a second one. UseShiny(...) goes on the host builder, Shiny’s modules are registered next to your own services, and your view models inject IConnectivity, INotificationManager or IJobManager like anything else. Shiny starts through Uno’s IServiceInitialize as soon as the container is built, whether or not the host is ever started.

The background-launch job is where Uno makes it hard. Uno calls OnLaunched only once an activity starts. With the Skia renderer, the Uno 6 template default, it doesn’t even create your App until then. A host built in OnLaunched, which is where the template builds it, doesn’t exist when Android starts the process for a job.

So your App implements IShinyUnoApplication. What the template does between CreateBuilder and NavigateAsync moves into a static ConfigureApp, and Shiny can build from it before there’s an App, a window or an activity:

public partial class App : Application, IShinyUnoApplication
{
    protected Window? MainWindow { get; private set; }
    protected IHost? Host { get; private set; }

    // runs once per process - on Android from Application.OnCreate
    public static void ConfigureApp(IApplicationBuilder builder) => builder
        .UseToolkitNavigation()
        .Configure(host => host
            .UseNavigation(RegisterRoutes)
            .UseShiny(services =>
            {
                services.AddConnectivity();
                services.AddJobs();
                services.AddNotifications<MyNotificationDelegate>();
            })
        );

    protected override async void OnLaunched(LaunchActivatedEventArgs args)
    {
        var builder = this.GetShinyBuilder(args);   // in place of this.CreateBuilder(args)
        this.MainWindow = builder.Window;
        this.Host = await builder.NavigateAsync<Shell>();
    }
}

On Android, one line in your NativeApplication builds the host at process start:

public override void OnCreate()
{
    base.OnCreate();
    this.StartShiny<App>();
}

When the user then opens the app, GetShinyBuilder hands OnLaunched the same builder, and NavigateAsync gets back the host that’s already running. NavigateAsync, Toolkit navigation and the extended splash screen work as they did. We checked this on an Android emulator: a process started with no activity brings Shiny up, and opening the app later in the same process attaches the window and navigation to that host, with Shiny started once.

Shiny ships no Android base classes for Uno. NativeApplication and ApplicationActivity are different types under Uno’s Skia and native renderers, so a base class built against one wouldn’t load under the other. Your activity keeps its own ApplicationActivity and overrides four methods to forward the events to Host.Lifecycle. The docs page has them ready to copy, along with one flag to set on Android notifications under the Skia renderer.

iOS needs no Shiny code: Uno calls OnLaunched from didFinishLaunching, background launches included. The Skia desktop and Windows heads use Uno’s DispatcherQueue as Shiny’s main thread.

Shiny’s browser modules (battery, connectivity, screen, BluetoothLE, GPS, push and more) are written against Blazor’s IJSRuntime, and Uno’s WebAssembly head doesn’t have Blazor. Shiny.Hosting.Uno.WebAssembly provides one:

.Configure(host => host
    .UseNavigation(RegisterRoutes)
#if __WASM__
    .UseShinyWebAssembly()
#endif
    .UseShiny(services => services.AddConnectivity().AddBattery())
)

It’s built on the .NET WebAssembly runtime’s own [JSImport] / [JSExport] interop and Microsoft.JSInterop’s JS dispatcher. It handles module imports, in-process calls and DotNetObjectReference callbacks, and Shiny’s scripts are served from _content/Shiny.*/ as static web assets, the same way as in Blazor. It also holds the first navigation until the browser monitors have loaded, so the first page shows real connectivity and battery values instead of Unknown. Reference it from the WebAssembly head only. Outside the browser it does nothing.

Each package has a sample in the repo:

• samples/Sample.Avalonia has desktop, Android and iOS heads.
• samples/Sample.Uno has Android, iOS, Skia desktop and WebAssembly heads, using the Skia renderer, Uno.Extensions navigation and the Toolkit extended splash.

Both show the platform, connectivity and when Shiny started. On Android and iOS they request notification permission, send a notification and show the tap.

One known gap: Uno 6.7’s iOS runtime has no scene delegate, and the iOS 27 SDK stops apps without one, so the Uno iOS head builds but won’t run on iOS 27 until Uno adds one.

The full setup is in Avalonia Hosting and Uno Platform Hosting, and the changes are in the release notes.

Packages

.NET — 1.16.0-preview.261029.1

Python — 1.0.0b261029

All .NET assemblies and packages in this release are Authenticode signed through ESRP.

Breaking changes

Microsoft.Agents.AI.DurableTask

• Default new agent sessions to dafx-v2-{agent} entities writing schema 2.0.0 state with automatic worker work-item filtering, reserve v{digits}- agent-name prefixes, add DurableAgentsOptions.ProcessLegacyEntities (DURABLE_AGENTS_PROCESS_LEGACY_ENTITIES) for Phase 2 registration and in-place 1.x to 2.0.0 migration of legacy dafx-{agent} entities after v1 workers are stopped, and expose public HistoryRetentionMode (KeepAll/Auto), MaxStateBytes (1 MiB default under Auto), HistoryRetentionHighWatermark, HistoryRetentionLowWatermark, and ResultRetentionPeriod on DurableAgentsOptions (#155)

Microsoft.Agents.AI.Hosting.AzureFunctions

• Emit dafx-v2-{agent} entity triggers by default and add dafx-{agent} triggers when DurableAgentsOptions.ProcessLegacyEntities (DURABLE_AGENTS_PROCESS_LEGACY_ENTITIES) is enabled in Phase 2, preserve full @dafx-... session IDs across HTTP/MCP round-trips when targeting legacy entities or @-prefixed session keys, reject cross-kind function name collisions across workflows, activities, and agent entities, and require "workItemFilteringEnabled": true in host.json (with Microsoft.Azure.Functions.Worker 2.52.0+, Microsoft.Azure.Functions.Worker.Extensions.DurableTask 1.19.0+, and Microsoft.Azure.Functions.Worker.Extensions.DurableTask.AzureManaged 1.10.0+) for side-by-side rolling upgrades or an offline cutover when host filtering is not enabled (#155)
• Surface durable mailbox terminal failures and unavailable results without successful fallback responses; change agent HTTP JSON status from a numeric HTTP code to the portable string state and add the numeric value as status_code; align outcome and x-ms-durable-outcome with the shared cross-runtime contract while retaining the previous .NET completion aliases; document responseFormat as a .NET-only MCP opt-in and preserve legacy text output by default. JSON clients comparing status to 200 or 202 must compare status_code instead (#94)

agent-framework-durabletask / agent-framework-azurefunctions

• agent-framework-azurefunctions: Migrated agent-framework-azurefunctions hosting to azure-functions-durable 2.x (Python 3.13+), rejected missing human-in-the-loop targets, and unified Python hosting package validation (#136)
• agent-framework-durabletask: Constrained standalone durable agent entity operations to explicit method references (#135)
• agent-framework-durabletask, agent-framework-azurefunctions: Added durable agent state schema 2.0 support, durable chat history ownership and session persistence, and pressure-based durable history retention (#123)

Fixes and improvements

• Updated Agent Framework dependencies to 1.23.0, preserved the orchestration synchronization context and one-shot message sequences, and released operation-scoped history overrides after successful service responses while retaining durable ownership and continuation validation (#116)
• Added default-off internal pressure-based durable transcript retention, escaped storage-envelope budgeting, atomic system/tool exchange grouping, checked signed-Int64 truncation evidence, and shared agent_framework.durabletask durable.retention.* attempt metrics while protecting schema 2 mailbox and execution-control state. Long client-side tool or approval chains can currently connect the protected component across the transcript and cause atomic write rejection at the budget; the default KeepAll behavior is unaffected, and linked-flow support remains tracked under #4 (#97)
• Added registration-scoped durable history configuration with validated DurableAgentHistoryProviderKey identities, explicit replay policy, schema-2 fixed owner bindings, pre-execution ownership validation, preserved schema-1 compatibility including configured in-memory provider reducer/filter state and a single model-input history source across cold restarts, and model-input compaction support without durable-store pruning. Upgrade with new durable sessions; keep sessions from older deployments isolated until explicit migration support is certified (#95)
• Hardened durable-agent mailbox delivery, duplicate correlation handling, working-state rollback, portable 60-second result retention, token-bounded result expiry, and stale-safe TTL deletion scheduling; reject case-variant recognized response-envelope duplicates before materialization and validate result-expiry batches once before staging payload removals and receipt transitions; added a default-off certified-provider finality path that atomically records sanitized failed results, accepted input, and serialized session evidence without inferring outcomes from exception text or status; preserved historical message boundaries, opaque schema-2 history/state profiles, and legacy response metadata through mailbox promotion; isolated untrusted response text and malformed activity/child payloads from workflow controls with all-or-nothing raw typed-message validation and preserved opaque child fallback routing (#94)
• Added passive .NET DTO, version-aware validation, converter, and source-generation support for the durable agent state 2.0 contract (#93)
• Prefer camelCase names on agent HTTP requests and responses (sessionId, waitForResponse, statusCode, completionOutcome) while retaining legacy snake_case request aliases and response fields during the migration window (#103)
• Updated Agent Framework dependencies to 1.23.0, including the compatible OpenAI dependencies used by the samples (#116)
• agent-framework-durabletask, agent-framework-azurefunctions: Added two-phase in-place entity schema migration (two_phase deployment mode, dafx-v2- entity and workflow naming, work-item filtering, and process_legacy_entities cutover) (#165)
• agent-framework-durabletask, agent-framework-azurefunctions: Added opt-in Azure Blob payload offloading (azure-blob-payloads extra) for standalone Durable Task and Azure Functions hosts, including offloaded workflow result reference resolution (#140)
• agent-framework-durabletask, agent-framework-azurefunctions: Shared the durable agent entity factory and workflow context across standalone and Azure Functions hosts (#134)
• agent-framework-durabletask, agent-framework-azurefunctions: Preferred camelCase names on agent HTTP requests and responses (sessionId, waitForResponse, statusCode, completionOutcome) while retaining legacy snake_case aliases (#103)
• agent-framework-durabletask, agent-framework-azurefunctions: Updated agent-framework-core dependency floor to >=1.19.0,<2 (#116)

Full changelogs

• Microsoft.Agents.AI.DurableTask
• Microsoft.Agents.AI.Hosting.AzureFunctions
• Python packages

I keep forgetting the MacBook Pro with PROLED XDR Display has a touchscreen. I've been testing this new laptop, one of the most impressive Apple has ever created, for the better part of a week. I can't stop noticing some of its other features: the slimmer design, the improved display, the Dynamic Island that somehow catches my eye more than the notch ever did. But I keep forgetting that as I go about my day, I can now reach out and poke the screen.

Come to think of it, that might be exactly what Apple intended. Steve Jobs said touch laptops were a bad idea; some subset of users demanded one anyway. Now the MacBook Pro has one. But not in a …

Read the full story at The Verge.

Discord is finally giving up on Electron, the cross-platform framework that lets developers build desktop apps using web technologies. Electron web apps are notoriously heavy on system resources, and Discord is now moving its desktop app fully to Rust - a modern programming language designed for speed and memory safety.

"We've been early adopters of Rust since 2018 and a lot of our infra, voice tech, and even some of the current client is already Rust, the holy grail was getting the whole client there," explains Discord chief technology officer Stanislav Vishnevskiy in a post on X. "That means Electron goes away, and so does React Native, m …

Read the full story at The Verge.

GoLand 2026.3 brings JetBrains Air into your Go workflow. You can run coding agents inside GoLand, review their changes alongside your code, and guide them with feedback tied to specific lines. A new GoLand skill helps agents use the profiler to investigate performance problems.

Additionally, this release improves Git worktrees, GoLand’s responsiveness, and support for working with remote projects. You will also find new ways to work with Figma designs and Kubernetes resources, automatic error and freeze reporting, and sound cues for IDE events.

JetBrains Air – one place to run your agents and verify their work

As of this release, JetBrains IDEs ship with Air, a new layer for agentic development. Work with the coding agents of your choice, and run, track, and verify multi-agent workflows inside your IDE, where code intelligence helps agents make fewer wrong turns and gives you the tools to review every change before it ships.

Your agents, your models, your subscriptions – with Junie Lite for free

Air works with Claude Agent, Codex, Gemini, GitHub Copilot, Junie, OpenCode, and other ACP-compatible agents. It detects the agents already installed on your machine so you can connect them in a click, and you can add more from the agent registry. Your existing setup carries over, too: Provider subscriptions, API keys, and even a custom base URL all work, with no JetBrains AI subscription required. Run Claude Agent on your Claude subscription in the terminal or in a full-screen IDE tab, use other agent subscriptions in the chat or terminal, and switch between subscriptions at any moment, even mid-session. Air includes free AI with the Junie Lite configuration, so you can use an agent without a subscription. You only need a JetBrains Account.

A central workspace to review changes and guide the agent

Review an agent’s changes with the surrounding code and your project tools in view, and send feedback straight back to the agent. Anchor a note to a specific line in the diff, or comment directly from the code, so the agent gets concrete context about the change you want. Work in the chat or the terminal, whichever suits you.

Still using AI Assistant? A notification will offer you a trial of Air. Moving to Air hides AI Assistant. If you wish to return to AI Assistant, follow the steps outlined here. Air automatically migrates your IDE skills, MCP configuration, agents installed through ACP, authentication, and chat history. Chat mode history isn’t migrated.

Option to profile Go applications with an agent

Agent skills are reusable instructions that tell an AI agent how to use GoLand’s tools for a particular task. The bundled profiler skill helps agents capture and analyze profiles, identify the functions and call paths that consume the most resources, and point you to source lines worth investigating.

This builds on the Go optimization tools introduced in GoLand 2026.2. Those tools bring profiling and performance data into the IDE. The new skill helps an agent use that data to investigate a slowdown and report what it found.

Improved performance

We investigated and fixed the most significant freezes reported through GoLand’s automatic reporting system.

Sound cues for IDE events and editor line marks

GoLand 2026.3 adds sound cues so you can hear important updates without looking at the relevant part of the screen. Builds, tests, and other background tasks use distinct sounds for success, warning, and error results. You can also hear when a breakpoint is hit.

For screen reader users, sound cues identify editor line marks: errors and warnings, lines added, changed, or removed under version control, and code folding. With screen reader support enabled, these cues and sounds for builds, tests, and breakpoint hits are on by default.

Agents in Air have sound cues enabled by default for everyone. You can hear when an agent finishes, stops with an error, or needs your input, and when dictation starts or stops.

Other sounds are optional. Explore and preview them on the Accessibility settings page, and use checkboxes in the Sound Signals section to enable cues for a notification group.

Git worktrees for parallel work and code reviews

GoLand can now copy your local project configuration into new Git worktrees, including run configurations and other settings stored in .idea. You can keep your setup without committing these settings to Git or recreating them for each worktree.

You can also list local and ignored files in .worktreeinclude for GoLand to copy, and configure a script to run when a worktree is created, for example, to install dependencies.

Other worktree improvements include:

• Support for projects with multiple roots.
• More reliable worktree creation in repositories with submodules.
• The option to check out a branch that is already checked out in another worktree, using --ignore-other-worktrees.
• Automatic removal of deleted worktrees from Recent Projects.
• Improved support for WSL and container projects.

Ability to find and fix problems faster

GoLand 2026.3 automatically sends error and UI freeze reports to JetBrains. The reports help us find and fix problems that may otherwise be hard to reproduce. They may include stack traces, error messages, and system information. Sensitive information in error messages is masked where possible.

You can turn off automatic reporting in Settings | Appearance & Behavior | System Settings | Data Sharing.

Figma design context for AI agents

If your Go project includes a frontend, Figma Connect lets you send design context from a selected Figma layer to an agent in GoLand. The agent receives the layer hierarchy, spacing, and design variables, so it can work from the design rather than a text description alone. Install the Figma Connect plugin to use this workflow.

Remote development directly from GoLand

GoLand now has an integrated connection flow for remote development. Connect to a machine over SSH, start a development session, or return to an existing one without leaving GoLand.

For remote projects with a Linux backend, Light mode opens the project before the remote IDE finishes downloading and starting. You can edit files, use the terminal, and search immediately. When the remote IDE is ready, your session moves to Smart mode and keeps your work and state.

GoLand also uses OpenSSH for remote connections. This improves compatibility with the SSH setup you already use, including certificates and hardware security keys.

Improvements for work with databases and files in Kubernetes

GoLand makes two common container tasks easier. From the Services tool window, you can create a database connection for a Kubernetes pod or Docker container. GoLand extracts the connection details for you automatically.

Moreover, you can now browse, view, create, and edit files inside a Kubernetes pod from GoLand.

Quick tasks and edits without opening a project

Not every task needs an open project. The redesigned Welcome screen, now called the Home window, offers a simpler in-editor view with fewer actions, so you can get to work the moment GoLand opens. Edit a file, run a terminal command, or perform Git actions – all without waiting for a full project to load.

Create a standalone file and start typing immediately, choosing its name and location when you save. When you need the full power of the IDE, your recent projects, along with actions to open or create a project, are on the left.

That wraps up the highlights of GoLand 2026.3. We would like to hear what you think. Share your feedback on X or create a ticket in our YouTrack issue tracker.

Happy coding,

The GoLand team