05 August

Designing High-Performance Custom Controls in .NET MAUI

By Jorge Perales Diaz MAUI

📖 Designing High-Performance Custom Controls in .NET MAUI

Building Fast, Scalable, and Maintainable UI Components

🧭 Introduction

One of the greatest strengths of .NET MAUI is its extensibility. While the framework includes a rich collection of built-in controls, real-world applications frequently require user interfaces that go beyond the standard components provided by the platform. Dashboards, calendars, financial charts, scheduling controls, maps, image editors, drawing surfaces, Kanban boards, media players, and countless other experiences often require developers to build their own reusable controls.

Creating a custom control in .NET MAUI is relatively straightforward. A developer can inherit from ContentView, compose existing controls, expose a few BindableProperty instances, and quickly obtain a reusable component that integrates naturally with the rest of the application.

However, creating a custom control that performs well under production workloads is a completely different challenge.

A control that behaves perfectly when instantiated once on a single page may become a significant performance bottleneck when repeated hundreds of times inside a CollectionView, updated continuously by real-time data, or displayed within complex visual hierarchies. In these scenarios, seemingly insignificant implementation details—such as unnecessary layout invalidations, deep visual trees, excessive property notifications, or repeated object allocations—can dramatically affect rendering performance, scrolling smoothness, memory consumption, battery usage, and overall application responsiveness.

These issues become even more noticeable in enterprise applications where custom controls often represent the majority of the user interface. A scheduling application may display thousands of appointments simultaneously. A logistics application may continuously update delivery routes. A financial dashboard may refresh charts several times per second. In each of these scenarios, the efficiency of the underlying controls directly impacts the user experience.

Designing high-performance controls therefore requires a shift in perspective. Rather than thinking exclusively about functionality, developers must understand how .NET MAUI measures layouts, synchronizes virtual views with native controls, propagates property changes, manages rendering, allocates memory, and ultimately displays pixels on the screen.

Throughout this article, we'll explore the engineering principles behind designing custom controls that remain responsive, scalable, and maintainable even under demanding production workloads. Instead of focusing on a particular UI component, we'll examine the architectural decisions that separate lightweight controls from those that gradually degrade application performance as complexity increases.

Among the topics covered are:

  • ✅ Choosing the appropriate base class
  • ✅ Understanding the visual tree
  • ✅ Layout performance
  • ✅ Measure and Arrange
  • ✅ BindableProperty optimization
  • ✅ Handler lifecycle
  • ✅ Rendering strategies
  • ✅ GraphicsView vs composed controls
  • ✅ Memory allocations
  • ✅ Object reuse
  • ✅ CollectionView optimization
  • ✅ Drawing performance
  • ✅ Profiling techniques
  • ✅ Common performance pitfalls
  • ✅ Best practices for enterprise applications

By the end of this guide, you'll have a deeper understanding of how .NET MAUI renders custom controls internally and how thoughtful architectural decisions can significantly improve both performance and maintainability.

🏗️ Choosing the Right Foundation

One of the earliest—and often most overlooked—design decisions when creating a custom control is selecting the correct base class.

Many developers instinctively derive every reusable component from ContentView because it offers an intuitive composition model and works well for many scenarios. While ContentView is an excellent choice for controls built by combining existing UI elements, it is not always the most efficient solution.

Every base class provided by .NET MAUI carries different responsibilities, lifecycle behavior, and performance characteristics. Choosing the appropriate foundation from the beginning often determines how scalable the control will remain as new features are added.

The framework provides several options.

Base Class Typical Use Case
ContentView Composite controls built from existing controls
TemplatedView Controls supporting customizable templates
GraphicsView High-performance drawing and visualization
Layout Custom layout containers
ScrollView Scrollable composite controls
Border Decorated content containers
View Lightweight controls backed by custom handlers

Each of these classes solves a different problem.

For example, suppose you're implementing a financial chart.

One possible solution consists of dozens of BoxView, Border, Grid, and Label elements.

Chart

↓

Grid

↓

Border

↓

BoxView

↓

Labels

↓

Lines

Although relatively easy to implement, this approach produces a large visual tree that must be measured, arranged, and rendered continuously.

A different approach uses GraphicsView to draw everything directly on a canvas.

GraphicsView

↓

Canvas

↓

Bars

↓

Lines

↓

Labels

Instead of creating hundreds of UI elements, the control becomes a single visual node capable of rendering thousands of graphical primitives efficiently.

Understanding when composition is appropriate and when drawing becomes the better solution is one of the first architectural decisions developers should make.

As a general guideline:

  • Choose ContentView when combining a small number of existing controls.
  • Choose GraphicsView when rendering many repeated visual elements.
  • Choose Layout only when designing a custom layout algorithm.
  • Derive directly from View when maximum control over the rendering pipeline is required.

Selecting the appropriate base class reduces complexity before a single line of business logic has been written.

🌳 Understanding the Visual Tree

Every control that appears on the screen becomes part of the application's visual tree.

This hierarchy describes how visual elements are nested and how layout information flows throughout the user interface. For example, consider the following custom card.

ContentView
    Grid
        Border
            Grid
                Image
                Label
                Label
                HorizontalStackLayout
                    Button
                    Image

Although visually simple, this control already contains multiple layouts, decorative containers, and rendering elements.

Now imagine displaying this control inside a CollectionView containing one thousand items.

The framework must now create, bind, measure, arrange, and render thousands of individual elements before the user can scroll smoothly.

The visual complexity grows exponentially.

CollectionView

↓

1000 Cards

↓

7000+ Visual Elements

Every additional UI element increases the amount of work performed during layout calculation and rendering.

This is why experienced UI engineers constantly evaluate the depth of the visual tree.

A flatter hierarchy generally results in:

  • Fewer layout calculations.
  • Less memory consumption.
  • Faster rendering.
  • Lower CPU utilization.
  • Improved scrolling performance.

Reducing unnecessary visual elements is often one of the simplest and most effective optimizations available. Developers frequently introduce additional layouts simply to achieve spacing or alignment. For example:

Grid

↓

VerticalStackLayout

↓

HorizontalStackLayout

↓

Border

↓

Label

In many cases, the same result can be achieved with a simpler hierarchy.

Grid

↓

Border

↓

Label

Although the visual difference is negligible, the rendering engine now performs considerably less work.

The cumulative impact becomes significant once controls are repeated hundreds or thousands of times throughout an application.

📐 Understanding Measure and Arrange

Every visual element displayed by .NET MAUI participates in the layout system.

Before a control can be rendered, the framework must determine two things:

  1. How much space the control would like to occupy.
  2. Where that control should ultimately be positioned.

These operations correspond to two distinct phases.

Measure

↓

Arrange

During the Measure phase, each control calculates its desired size based on the constraints imposed by its parent.

Once every child has reported its preferred dimensions, the parent decides the final layout.

The Arrange phase then assigns the actual size and position that each control will occupy.

This process propagates recursively throughout the entire visual tree.

Window

↓

Grid

↓

ContentView

↓

Border

↓

Label

Every layout pass requires each participating element to measure itself before the final arrangement can occur. Consequently, unnecessary layout invalidations quickly become expensive.

A custom control that repeatedly requests new measurements forces the framework to recalculate layout information not only for itself, but potentially for every affected ancestor and descendant. Understanding this propagation mechanism is fundamental when optimizing custom controls for high-performance scenarios.

⚡ Reducing Layout Invalidations

One of the most common performance issues found in custom controls is excessive layout invalidation. Whenever a control calls methods such as:

InvalidateMeasure();

or

ForceLayout();

the framework assumes that the current layout may no longer be valid and schedules another layout pass.

Although this behavior is entirely correct, unnecessary invalidations can become surprisingly expensive.

To understand why, it is important to remember that layout calculations are recursive.

A single invalidation does not necessarily affect only one control.

Window

↓

Grid

↓

CollectionView

↓

Item

↓

Custom Control

↓

Label

If the custom control requests a new measurement, every ancestor involved in determining its size may also participate in another layout calculation.

When this occurs hundreds of times per second—for example during animations or live updates—the amount of work performed by the layout engine increases dramatically.

For this reason, developers should carefully evaluate whether a property modification truly affects the size of the control.

Consider the following property.

public Color BackgroundColor
{
    get => _backgroundColor;

    set
    {
        _backgroundColor = value;
        InvalidateMeasure();
    }
}

Changing the background color does not alter the desired size of the control.

Requesting another measurement is therefore unnecessary.

A more appropriate implementation simply redraws the control.

public Color BackgroundColor
{
    get => _backgroundColor;

    set
    {
        _backgroundColor = value;
        Invalidate();
    }
}

On the other hand, changing the displayed text may legitimately require another measurement because the preferred width or height of the control could change.

Understanding this distinction is fundamental when designing efficient controls.

As a general guideline:

Property Change Requires Measure?
Background Color ❌ No
Border Color ❌ No
Shadow ❌ Usually No
Opacity ❌ No
Translation ❌ No
Rotation ❌ No
Width Request ✅ Yes
Height Request ✅ Yes
Font Size ✅ Yes
Text ✅ Usually
Image Source ⚠️ Depends

The fewer unnecessary measurements a control performs, the smoother the overall user interface becomes.

🏷️ Designing Efficient Bindable Properties

BindableProperty is one of the core building blocks of reusable MAUI controls.

It enables data binding, styling, animations, triggers, and XAML integration.

However, every bindable property also introduces additional work.

Whenever its value changes, the framework must:

  • Store the new value.
  • Compare it with the previous value.
  • Invoke callbacks.
  • Notify bindings.
  • Potentially invalidate layout.
  • Potentially redraw the control.

Because of this, every bindable property should exist for a clear reason.

It is surprisingly common to encounter controls exposing dozens of properties that are never customized by consumers.

Title

Subtitle

Icon

IconColor

IconMargin

IconSize

CornerRadius

ShadowColor

ShadowOpacity

ShadowBlur

...

Although flexibility is valuable, excessive configurability often increases maintenance complexity without providing proportional benefits.

A better approach is to expose only the properties that truly define the public behavior of the control.

This results in a simpler API surface and reduces the amount of work performed whenever state changes occur.

🔄 Property Changed Callbacks

Property change callbacks deserve special attention because they execute every time a bindable property changes. A native implementation often performs far more work than necessary.

private static void OnTitleChanged(
    BindableObject bindable,
    object oldValue,
    object newValue)
{
    var control = (MyControl)bindable;

    control.BuildEntireVisualTree();
}

Rebuilding an entire control because a single property changed quickly becomes expensive. Instead, callbacks should update only the components directly affected.

private static void OnTitleChanged(
    BindableObject bindable,
    object oldValue,
    object newValue)
{
    var control = (MyControl)bindable;

    control._titleLabel.Text = (string)newValue;
}

The amount of work performed should always be proportional to the actual change. This principle becomes increasingly important as controls become more sophisticated.

🎨 Composed Controls vs Drawing

One of the most significant architectural decisions when building custom controls is determining whether the control should be composed from existing UI elements or drawn directly.

A composed control may look like this.

Border

↓

Grid

↓

Image

↓

Label

↓

Button

Each element participates independently in:

  • Layout
  • Measurement
  • Binding
  • Rendering
  • Accessibility
  • Hit Testing

This approach offers excellent flexibility and accessibility but introduces additional overhead.

Drawing-based controls follow a different model.

GraphicsView

↓

Canvas

↓

Shapes

↓

Text

↓

Images

From the framework's perspective, the entire control becomes a single visual element.

Instead of managing dozens of child controls, MAUI simply asks the canvas to paint its contents.

For highly visual controls—such as calendars, charts, timelines, seating maps, schedulers, or diagram editors—this approach can dramatically reduce the size of the visual tree while improving rendering performance.

However, drawing is not always the right solution.

The following comparison illustrates the trade-offs.

Composed Controls GraphicsView
Native accessibility Manual accessibility
Native focus handling Manual focus handling
Automatic bindings Manual state management
Easier maintenance More rendering code
Rich styling support Custom drawing required
Better for forms Better for visualizations

Choosing between these approaches depends entirely on the nature of the control being developed.

🧵 Understanding the Handler Lifecycle

Every visual element in .NET MAUI is ultimately connected to a native platform control through a handler. The lifecycle follows a predictable sequence.

VirtualView

↓

Handler Created

↓

PlatformView Created

↓

ConnectHandler()

↓

Property Mapping

↓

Rendering

↓

DisconnectHandler()

↓

Dispose

Understanding this lifecycle is essential because many resource leaks originate from code executed during handler initialization.

For example, event subscriptions established inside ConnectHandler() should almost always be removed during DisconnectHandler().

Connect

↓

Subscribe Native Events

↓

Application Runs

↓

Disconnect

↓

Unsubscribe Native Events

Forgetting to remove native event handlers may prevent controls from being garbage collected, even after they disappear from the user interface.

Custom controls that allocate timers, platform listeners, gesture recognizers, or unmanaged resources should treat the handler lifecycle as the natural place for both initialization and cleanup.

💾 Reducing Memory Allocations

Smooth rendering depends not only on CPU performance but also on memory allocation patterns.

Every allocation eventually contributes to garbage collection.

Although modern garbage collectors are highly optimized, unnecessary allocations performed continuously during rendering can introduce visible frame drops.

Consider a control that recreates the same objects every time it redraws.

Frame 1

↓

New Brush

New Pen

New Font

↓

Frame 2

↓

New Brush

New Pen

New Font

↓

Frame 3

...

Thousands of short-lived objects accumulate quickly. Instead, reusable objects should be created once whenever possible.

Initialize

↓

Create Brushes

Create Pens

Create Fonts

↓

Reuse

↓

Reuse

↓

Reuse

Reducing allocation frequency decreases garbage collection pressure and results in smoother animations and scrolling.

♻️ Reusing Objects

Many custom controls repeatedly create identical resources despite their properties remaining unchanged.

Typical examples include:

  • Brushes
  • Colors
  • Pens
  • Paint objects
  • Geometries
  • Fonts
  • Images
  • Text layouts

Whenever these objects are immutable—or change infrequently—they should be cached and reused.

Object reuse not only reduces allocations but also minimizes the amount of initialization work performed during rendering.

This optimization becomes increasingly valuable in controls that redraw dozens of times per second.

📱 Optimizing Controls for CollectionView

One of the fastest ways to expose performance issues in a custom control is to place it inside a CollectionView.

A control that appears perfectly responsive when displayed once may behave very differently when hundreds or even thousands of instances are created, measured, bound, and recycled while the user scrolls through a large data set.

Consider a typical product catalog.

CollectionView

↓

Product Card

↓

Image

↓

Title

↓

Price

↓

Rating

↓

Actions

Now imagine displaying one thousand products.

Even though only a small number of items are visible at any given time, the framework continuously creates, measures, binds, arranges, and recycles controls as the user scrolls.

If the custom control performs unnecessary work during initialization or property updates, those costs quickly accumulate.

For this reason, controls intended for virtualization should follow a few important principles.

Avoid expensive initialization logic inside constructors. Constructors should prepare the control, not populate it with data or perform heavy computations.

Likewise, property change callbacks should update only the portions of the UI affected by the new value rather than rebuilding the entire control.

Whenever possible:

  • Delay expensive operations until they are actually required.
  • Cache reusable resources.
  • Avoid repeatedly allocating brushes, images, or fonts.
  • Minimize layout invalidations.
  • Avoid synchronous file or network access during initialization.

Controls that follow these principles integrate much more efficiently with MAUI's virtualization mechanisms.

🖼️ Optimizing Rendering Performance

Rendering is often confused with layout, although they represent different stages of the rendering pipeline.

Once the layout engine determines where each control should appear, the rendering system becomes responsible for drawing the final result on the screen.

Every visual element contributes to this process.

For composed controls, rendering consists of traversing every visual element individually.

Border

↓

Grid

↓

Image

↓

Label

↓

Button

Each element requires its own rendering work.

In contrast, drawing-based controls using GraphicsView perform rendering through a single drawing operation.

GraphicsView

↓

Canvas

↓

Draw()

This difference becomes increasingly important when rendering highly repetitive content.

Examples include:

  • Financial charts
  • Calendars
  • Seating maps
  • Timelines
  • Diagrams
  • Heat maps
  • Schedulers

Replacing hundreds of visual elements with direct drawing often reduces rendering overhead while producing significantly smoother scrolling.

However, rendering efficiently is not simply about drawing fewer objects.

Developers should also consider:

  • Redrawing only the regions that changed.
  • Avoiding unnecessary overdraw.
  • Reusing drawing resources.
  • Reducing transparency when possible.
  • Minimizing clipping operations.
  • Avoiding repeated text measurements during every frame.

Small improvements in rendering efficiency often produce disproportionately large improvements in perceived application responsiveness.

📊 Profiling Custom Controls

Performance optimization should always be driven by measurements rather than assumptions.

Developers frequently spend considerable time optimizing areas of code that contribute very little to overall execution time while overlooking the operations that truly affect responsiveness.

Profiling provides objective data that guides optimization efforts.

Several tools can be used when evaluating custom controls.

Tool Purpose
Visual Studio Profiler CPU and memory analysis
Performance Profiler UI responsiveness
dotnet-trace Runtime event tracing
dotnet-counters Runtime performance counters
Android Studio Profiler Android memory and rendering
Xcode Instruments iOS performance analysis

These tools help answer questions such as:

  • Which methods allocate the most memory?
  • Which property changes trigger repeated layouts?
  • How frequently is the control measured?
  • How much time is spent rendering?
  • Are objects being garbage collected as expected?
  • Are controls properly disposed after navigation? Without profiling, optimization often becomes guesswork. With profiling, developers can focus on the operations that actually affect performance.

🧪 Measuring Before Optimizing

An important principle in performance engineering is avoiding premature optimization.

Not every custom control requires the same level of optimization.

A control displayed once on a settings page has very different performance requirements than one displayed hundreds of times inside a virtualized list.

Before investing time in optimization, ask a few simple questions.

  • Is the control instantiated frequently?
  • Does it participate in scrolling?
  • Is it continuously updated?
  • Does it perform custom drawing?
  • Does it allocate many temporary objects?
  • Does profiling identify it as a bottleneck?

If the answer to most of these questions is no, additional optimization may provide little practical benefit. Performance work should always be proportional to the problem being solved.

⚠️ Common Performance Pitfalls

Many performance issues originate from a relatively small set of recurring mistakes. Understanding these patterns makes them significantly easier to avoid.

Deep Visual Trees

Every additional visual element increases layout and rendering work. Whenever possible, flatten the hierarchy and eliminate unnecessary containers.

Excessive Bindable Properties

Every bindable property introduces change tracking, callbacks, and binding notifications. Expose only the properties that represent meaningful customization points.

Rebuilding Instead of Updating

A single property change should update only the affected portion of the control. Avoid recreating the entire visual hierarchy when only one element changes.

Frequent Layout Invalidations

Calling InvalidateMeasure() unnecessarily forces the layout engine to perform additional work. Invalidate only when the desired size of the control has actually changed.

Unnecessary Allocations

Repeated creation of temporary objects increases garbage collection pressure. Prefer caching and object reuse whenever possible.

Ignoring Disposal

Timers, event subscriptions, animations, platform listeners, and unmanaged resources should always be released when the control is no longer needed. Failure to do so often results in memory leaks that become increasingly difficult to diagnose.

Performing Heavy Work on the UI Thread

Rendering, binding, and layout already execute on the UI thread. Additional expensive computations should generally be moved to background threads whenever possible.

📊 Design Strategy Comparison

Different implementation strategies involve different trade-offs. Selecting the appropriate approach depends on the requirements of the control rather than personal preference.

Strategy Flexibility Performance Complexity Typical Use Cases
Composed Controls (ContentView) ⭐⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐ Forms, dialogs, reusable UI components
Drawing (GraphicsView) ⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ Charts, calendars, timelines, visualizations
Custom Layouts ⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐⭐ Specialized layout containers
Native Handlers ⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ Platform-specific controls requiring maximum performance

There is no universally correct choice. Each approach represents a balance between maintainability, flexibility, and rendering efficiency.

✅ Key Benefits

Designing high-performance custom controls provides benefits that extend well beyond rendering speed.

  • 🚀 Improves application responsiveness by reducing unnecessary layout and rendering work.
  • 📱 Delivers smoother scrolling experiences in virtualized collections.
  • 💾 Reduces memory allocations and garbage collection pressure.
  • 🔋 Lowers CPU utilization, contributing to better battery life on mobile devices.
  • 🧩 Produces cleaner, more maintainable control architectures.
  • 📈 Scales more effectively as applications and datasets grow.
  • 🎨 Enables richer user experiences without sacrificing responsiveness.
  • 🔍 Simplifies performance analysis through well-structured control design.

🔚 Final Thoughts

Building a custom control is relatively easy. Building one that continues to perform efficiently as applications grow is considerably more challenging.

High-performance controls are rarely the result of a single optimization. Instead, they emerge from a series of thoughtful architectural decisions made throughout the design process. Choosing the appropriate base class, minimizing visual tree complexity, understanding the layout system, optimizing property updates, reducing allocations, respecting the handler lifecycle, and selecting the correct rendering strategy all contribute to the overall responsiveness of the application.

These considerations become increasingly important in enterprise applications where custom controls often represent the primary building blocks of the user interface. Controls that perform efficiently in isolation but degrade under heavy workloads can negatively affect scrolling performance, memory usage, battery life, and overall user experience.

By understanding how .NET MAUI measures, arranges, renders, and synchronizes visual elements with native platform controls, developers can create reusable components that remain both powerful and efficient throughout the lifetime of the application.

Ultimately, designing high-performance controls is not about writing more complex code. It is about understanding how the framework works internally and making architectural decisions that allow the framework to do less work while delivering a smoother and more responsive user experience.

📚 Additional Resources

If you'd like to explore custom control development and performance optimization in greater depth, the following official resources are excellent references:


Was this useful?

Comments (0)

Leave a comment

Submit for moderation

Designing an Enterprise Logging Architecture for .NET MAUI

Learn how to design a production-ready logging architecture for .NET MAUI using structured logging, correlation IDs, contextual enrichment, asynchronous processing, secure data redaction, and cloud observability to build scalable, secure, and highly maintainable mobile applications

MAUI - Advanced Dynamic Custom Controls

Advanced dynamic custom controls are data-driven, interactive components that adapt at runtime. They combine powerful binding capabilities with customizable behavior, making them ideal for complex UI

An unhandled error has occurred. Reload 🗙