I know you are all working on this and are addressing the breaking changes between preview7 to RC1, I wanted to open this Feature Request so that I can be immediately notified when UI for MAUI RC1 support is ready to download and use.

Thank you,

Denis

When you release your MAUI components, can you please provide well designed working sample projects so that your customers can get started quickly.

These projects should be fully working Line of Business (LoB) apps which is your target market i.e. customers like me.

These samples should connect to ReST Web API's (as is the case with all my KendoUI projects), with a login screen, and then desktop, tablet and mobile 'personalities' with navigation bar, hamburger side menu, caption, search, account drop down, CRUD etc... i.e. all the things modern apps have these days.

You should also produce a 'kitchen sink' app which demonstrates the use of every component in a simple 'app' without use of overly complex code which could confuse or intimidate your customers.

Remember, you are the experts, not your customers, else we would not be buying your products, we'd build our own. Help us to build cool products with your components.

If you have read the famous 'mythical man month', Brookes recommends buying components, especially big ones, the bigger the better. He means buying fully scaffolded, working, documented, easy to understand, application source code e.g. LoB projects which you are best placed to construct for our benefit. Progress has many excellent tech evangelists, I have watched their presentations, and I'd like to see these people involved in constructing these LoB sample apps, as their video presentation skills will also benefit your customers in understanding best practice for building LoB apps.

I hope this helps?

Kind Regards

Garry

Hi Team,

I would like to be able to have a Ribbon component for Windows and MacCatalyst that is just as feature rich as the UI for WPF RibbonView (or at least similar to the UI for WinUI RibbonView).

Hi Team,

Please introduce a SignaturePad control to Telerik UI for Maui.

Manish

Hi Team,

I prefer C#, so I am looking for resources that are not using XAML. Can you please make a duplicate of all your demos and documentation mentions so that we can toggle between XAML and C#.

Thank you

Joesph

Hi,

Do you have on your roadmap to include a Shimmer View / Control as part of your .NET MAUI offerings to tidy up a screen loading indication.

From a UI/UX perspective, a shimmer sits better with our user community rather than a loading indicator.

Thank you,

Shane

After updating our Maui application to Maui version 8.0.90, the Entry controls in the WinUI version stopped responding to WidthRequest, HorizontalOptions, or parent container sizes. I thought it was just a Maui problem, but in the relevant issue's notes, I saw that users were having trouble duplicating it unless Telerik UI for .NET Maui was installed (https://github.com/dotnet/maui/issues/24783).

So I created a test app that contains a few Entry controls in various containers:

<?xml version="1.0" encoding="utf-8"?>

<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             x:Class="WinUIEntryBug.MainPage">

    <ScrollView>
        <VerticalStackLayout
            Padding="30,0"
            Spacing="25">

            <Border>
                <Entry />
            </Border>

            <Grid>
                <Grid.ColumnDefinitions>
                    <ColumnDefinition Width="*" />
                </Grid.ColumnDefinitions>

                <Entry Grid.Column="0"></Entry>
            </Grid>

            <Frame>
                <Entry />
            </Frame>

            <Entry />
        </VerticalStackLayout>
    </ScrollView>

</ContentPage>

Without the Telerik components added to the project, the Entry boxes render correctly:

But, when I add a reference to Telerik UI for .NET Maui version 7.1.0 (latest at the time this was written), I get this:

Note: I didn't even add UseTelerik() to the Builder in the MauiProgram.cs, just added the Nuget package.

Changing the WidthRequest, HorizontalOptions, MinWidthRequest, etc. does not affect their size. They do render correctly in iOS and Android, though.

If I then remove the UI for .NET Maui Nuget package, they go back to working.

In our main application, we are heavily dependent on Telerik components and have a substantial number of customers using the Windows version of our application, so this heavily impacts our ability to ship. Particularly since the Maui 8.0.90 fixes other bugs that we needed addressed.

I've attached my sample project with the Telerik UI for .NET Maui package installed. You can remove it to see the normal operation of the Entry boxes.

Hi Team,

Currently, Telerik UI for MAUI works implicitly with the standard MSIX packaged WinUI 3 app. However, if I manually bypass that and use msbuild to build an unpackaged, self-contained exe, some of the resources are not embedded.

This feature request is for UI for MAUI to implicitly support unpackaged apps without the developer needing to do anything for the destination environment (fonts, etc.)

Hi Team,

Although UI for MAUI does not have a Calendar/Scheduler control... you're still forcing us to declare a NSCaldendarsUsage permission in info.plist because of some old code inside the native iOS static library inherited from UI for Xamarin.

I have some requests/comments for you:

• Please remove this from the native iOS static library, there is no use for it at the moment.
  
• If you plan on bringing the old Xamarin Calendar to the MAUI with the new handler architecture; please split up the iOS libraries so that the Calendar's use of this API can be linked out during compilation.
• If you are going to build a new calendar/scheduler using modern MAUI layers; please allow non-Calendar consumers to not require any permissions that Calendar may need.

I do understand that if I'm not using the Calendar in my app, the user will not be explicitly asked to approve permissions. However, this is unacceptable excuse because my org's application only uses the RadListView, but we still have to show that the calendar is a potential access point in the permissions manifest.  In the world of security conscious users and enterprise security audits, this explanation is tiresome to hold up.

We've known about this problem for many years, and hopefully .NET MAUI can be a fresh break away from the headaches of Xamarin.

Thank you for your time and consideration,

Gerard