Replies: 13 comments 59 replies
-
|
We migrated our app from xamarin to MAUI on .NET 8 and are now on .NET 9. Initially everything was a big pain. Now things are kinda smooth, comparable to how they were on xamarin. We are not using Shell! But this is just for our project, I see some other people still struggle more. Generally you still need to work around a lot of smaller quirks, but that was already the case in xamarin. My biggest pain is that the performance on Android is terrible. Regarding rider it works quite fine now. There is some issues for me still where builds will randomly fail and debugging/hot reloading will not work and I need to clean the project and delete .idea files, this is a pain sometimes. MAUI is not great but it does its job for the most part. I would still be hesitant to recommend anyone using it because of all the quirks, performance issues and instabilities. |
Beta Was this translation helpful? Give feedback.
-
|
As far as I know, Xamarin support will end in May 2024, right? For me there is no question about MAUI team regarding the MAUI issues, the guys give the best of themselves. But what I keep asking myself is if c-suite from Microsoft is still alive on this planet earth? Because how can you remove support from Xamarin when MAUI is not yet mature (even if it was released 2 years ago)? Maybe Microsoft also hopes that there will only be programmers in this year 2025 and after that no more because AI will take over everything (Mark Zuckerberg)? pc |
Beta Was this translation helpful? Give feedback.
-
|
To be fair it seems we are going back rather than going forward. I hope things will get better but for now I'm not very confident about it. |
Beta Was this translation helpful? Give feedback.
-
|
@phillippschmedt Could you try #27259 if it fixes your performance issue? Any feedback there is tracked by the MAUI team, so it's useful to present there any positive impact, if any. |
Beta Was this translation helpful? Give feedback.
-
|
Well, my main issue nowadays is regarding tooling. Still an awful experience, either using Rider, or Visual Studio for Windows, (rider is better though). The classic clean, delete bin/objs, fonts not being rendered, etc, hot reload stopping to work. On the positive side, my experience so far has been good regarding the framework itself. Not that many issues regarding performance ( thgough previous knowledge from Xamarin helps a lot, Visual Tree, simplification of xaml, some controls in pure c#, MVVM, less packages). One thing people keep forgetting - debug is WAY slower in MAUI rather than xamarin. but like 4/5 times slower. If you go to a release version the app seems like another one. Still, there is a long road ahead, with many critical bugs, (or just simple ones) to be fixed, but things are going forward at least |
Beta Was this translation helpful? Give feedback.
-
|
I'm aware about the debug and that's fine... it's the release that I'm complaining about. Everything is slow without reason. I used a syncfusion calendar component for one of my client's app but it was too slow and I had to rewrite it from scratch to make it decent so it's not how I write code. I loved Xamarin and love C# but this team need more resources to do something good |
Beta Was this translation helpful? Give feedback.
-
|
#27042 seems to improve perf considerably for all platforms. See the perf impact section. There is much more that can be achieved with this approach. But even with this PR, a big group of apps might turn from slow to okay performance-wise. One can even somehow download nugets for that PR to check it out now, but I'm not sure how at the moment. |
Beta Was this translation helpful? Give feedback.
-
|
With MAUI I only use Blazor and don't really experience these performance problems. I have the impression that the majority of MAUI problems are caused by XAML, but can @MartyIX please clarify this because you are dealing with it? Thanks. |
Beta Was this translation helpful? Give feedback.
-
|
More in-depth reasons are mentioned in the PR. But in short: MAUI on Windows/Android/etc. requires interop calls to propagate virtual views changes to platform views. These are costly, #27042 reduces significantly the number of such calls. Personally, I don't think that XAML is the issue. |
Beta Was this translation helpful? Give feedback.
-
the nugets are on Generally speaking, I have to say that the performance in release mode is now great if you have the resources and the will to optimize your code and xaml |
Beta Was this translation helpful? Give feedback.
-
|
Does this already contain #27042?
Not sure about the comment about optimizing code and xaml..
Is this related to this build or a generic comment?
…On Mon, 20 Jan 2025, 15:18 Nico, ***@***.***> wrote:
#27042 <#27042> seems to improve perf
considerably for all platforms. See the perf impact section. There is much
more that can be achieved with this approach. But even with this PR, a big
group of apps might turn from slow to okay performance-wise.
One can even somehow download nugets for that PR to check it out now, but
I'm not sure how at the moment.
the nugets are on
https://dev.azure.com/xamarin/public/_build/results?buildId=132815&view=artifacts&pathAsName=false&type=publishedArtifacts
--> nuget
--> 3-dot menu (appearing on mouseover)
--> download artifacts
Generally speaking, I have to say that the performance in release mode is
now great if you have the resources and the will to optimize your code and
xaml
—
Reply to this email directly, view it on GitHub
<#27185 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAUIPIWKXLXOHM67TMXPVET2LUHTXAVCNFSM6AAAAABVKAC3KCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCOBZGE4DCOI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
That is my own general opinion regarding performance at the moment, even without #27042 It helps a lot to create ViewModels in background threads and only set the ViewModel in the view as a BindingContext when all properties have their value. Especially IsVisible properties. And of course don't create unnecessary controls and then hide them with IsVisible="false". |
Beta Was this translation helpful? Give feedback.
-
|
@marcojak I was talking about some general considerations ( most of them are pointed in the performance section of MAUI). Keep the Visual Tree as slim as possible. One of the advantages or disadvantages of XAML is that you can have the same layout constructed in different ways ( VerticalStacklayouts, grids, etc): I tend to use as many Grids as possible. Regarding the VMs, the same comment as @baaaaif , background whenever possible, async awaits, offload from MainThread whenever possible ( see ConfigureAwaits in your HTTP Requests and other possible tasks) |
Beta Was this translation helpful? Give feedback.
-
|
OK, I overlooked one thing - for me this is only the case on iOS and Android if UseInterpreter=False(iOS) / RunAOTCompilation=True(Android) are set. |
Beta Was this translation helpful? Give feedback.
-
|
These are all great suggestions but unfortunately, MAUI is for some reason slower than Xamarin Forms. This is true especially for iOS where X.F. was really smooth on iOS and really slow with MAUI. In addition to this, I see some strange behaviours in one of my sporting from XF to MAUI (but I still have to investigate them so I haven't opened any issues yet), where some controls just disappear from my CollectionView and others are not properly updated. I'm not saying it's all bad, but just that there is a lot of room for improvements |
Beta Was this translation helpful? Give feedback.
-
|
Try MauiReactor |
Beta Was this translation helpful? Give feedback.
-
|
I didn't know about it. I'll have a look. Thanks |
Beta Was this translation helpful? Give feedback.
-
|
Here are some important links for MauiReactor: https://github.com/adospace/reactorui-maui https://github.com/adospace/mauireactor-samples |
Beta Was this translation helpful? Give feedback.
-
|
I think in 2025 we should continue to accelerate the resolution of bugs and optimize the logic at the same time. By using AI analysis to improve the code, the problem of maui being slow may be improved. |
Beta Was this translation helpful? Give feedback.
-
|
Just as an update. I've published my client latest app yesterday, both on Android and iOS. |
Beta Was this translation helpful? Give feedback.
-
|
Personally, I had to create a customised Calendar with a custom cell for each day. Also getting rid of the CarouselView, replaced by another control made by other developers, solved almost all problems, we went from more than 400 crashes in 1 day to just 1 today. I really hope the team will get rid of the CarouselView and replace it with another component. Regarding Blazor, unfortunately, I have no real experience with it (I've done a few tests to see if it was mature enough) so I cannot say. My feeling anyway is that Blazor shouldn't have the same performance issues |
Beta Was this translation helpful? Give feedback.
-
|
@marcojak what pre-release already includeshttps://github.com//pull/27042 ? |
Beta Was this translation helpful? Give feedback.
-
It's a pull request, so one can download nugets for the PR. It's not in the nightly feed because it was not merged. And it is a good question if it will be ever merged because @albyrock87 presented #27259 which seems to be an even better implementation of what I wanted to achieve. You can check out the perf improvements of his PR1. Footnotes
|
Beta Was this translation helpful? Give feedback.
-
|
Thank you. Anyway, whatever will be chosen, will be a good improvement! |
Beta Was this translation helpful? Give feedback.
-
I don't want to a bearer of bad news but ... I sincerely doubt that 😂. It's a non-trivial change so I don't expect it. But sometimes miracles happen. |
Beta Was this translation helpful? Give feedback.
-
|
In 2025, we still using Xamarin.Forms, Xamarin.Android, and Xamarin.iOS. Why we still using Xamarin? Because migration to MAUI is painfull, we have a lot custom handler, and too much components must be enchance. MAUI is good for .NET developer to craft some mobile apps, but if you wont to migrate, consider to re-write all source to another crossplatform framework (RN or Flutter). |
Beta Was this translation helpful? Give feedback.
-
|
You would have the energy and resources to rewrite to another framework, but you would not have the energy and resources to rewrite some of your old custom handlers and components to a more modern and performant platform - .NET Maui? Doesn't the reasoning seem nonsensical to you? |
Beta Was this translation helpful? Give feedback.
-
|
@saint4eva please try development in macos if you want know developing .NET MAUI and you want to throw you energy to .NET MAUI. |
Beta Was this translation helpful? Give feedback.
-
|
@raselldev how you will compile Xamarin apps with iOS 18 (required from April 2025) and Android 15 (required from August 2025)? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, so you now, i think compile iOS with xcode 15 but starting from April 2025 how you compile Xamarin with xcode 16? |
Beta Was this translation helpful? Give feedback.
-
|
I can build xamarin app with ios18.2 SDK in the following environment. For Android, install the Android SDK and tools that support API Level 35 and set the targetSdkVersion in AndroidManifest.xml to 35. |
Beta Was this translation helpful? Give feedback.
-
|
I'm also still using Xamarin.Forms. I've changed my Xamarin.Forms app so that it would target Android 15 to prolong it's life a bit. I've just installed Android SDK for Android 15 and edited the target version in AndroidManifest.xml. It was simpler than I had thought. I just needed to opt-out from edge-to-edge mode afterwards and that was it. I've published it to Google Play and it works well. However, it gave me just a few months. From November 1st, 2025, Google Play will require apps to support 16 KB memory pages. This is supported in MAUI but not in Xamarin.Forms. I've almost finished migration to MAUI for Android. I've uploaded MAUI version of my app to the Google Play internal testing channel to try it. It was surprisingly smooth process. And there is a really nice performance boost compared to Xamarin.Forms version. On the other hand publishing Windows version to Microsoft Store turn out to be a nightmare for the app updated to MAUI and I have not been able to solve it yet. |
Beta Was this translation helpful? Give feedback.
-
|
@holecekp Is there an issue for the Windows issue? |
Beta Was this translation helpful? Give feedback.
-
|
@MartyIX I've reported there: https://developercommunity.visualstudio.com/t/Missing-option-in-VS-for-publishing-NET/10918920?viewtype=all Besically, I have troubles associating the MAUI app with the existing app in Microsoft Store (which was no problem for the original Xamarin.Forms version of the app). Additionally, I updated MAUI from 9.0.70 to 9.0.80 and the app started crashing with the code 2147942405 (0x80070005) on Windows, so I reverted back to the origianl MAUI 9.0.70 but the crashes still persist (???). I've deleted bin and obj folders, restarted computer but still the MAUI app could not run on Windows anymore. Then I spent some time googling and found that this might be the issue #12080. It's from the year 2022 and marked as closed but apparently it's still a problem also in 2025. I've added |
Beta Was this translation helpful? Give feedback.
-
|
Hmm, .NET MAUI is not that bad actually. I am just finishing the development of a .NET MAUI 8 App for Android and iOS and the framework was pretty descent, actually. It is not a huge app but includes many features (user management through an API, a mechanism to maintain state between views, barcode scanning, search-enabled, dynamic CollectionViews and even forms dynamically created in code, etc) that were all implemented nicely in a MVVM fashion. It is a wizard-like app and I did use Shell, which worked as expected, too, even though it took me some time to understand its twists and bolts. Also, MAUI XAML (2021) is a bliss compared to WPF XAML (2009), really. Overall, a very good experience. I had heard LOTS of bad things and rants about .NET MAUI but decided to go for it and I cannot say I got disappointed in any major way. Things do work and the official documentation is good enough (compared to ChatGPT and StackOverflow that misled me most of the times). |
Beta Was this translation helpful? Give feedback.
-
|
I'd say things are a lot better now that things have had some time to stabilize after the dotnet 9 release. Yeah, there are some bugs still, and the performance could be improved a bit. Generally though, things are getting to be pretty smooth. For the most part the apps are pretty snappy in terms of startup and runtime performance. The MAUI team are pretty responsive I find. Certainly beats developing multiple native apps, especially if you already have C# experience and/or an existing C# app you need to port. Release builds for iOS are abominably slow, but that takes place on CI and only when publishing so doesn't affect the dev cycle too much. EDIT: iOS arm64 simulator release build performance can be improved to match release publish performance with: Using MVVM can mitigate some of the risks if you wanted to jump ship to AvaloniaUI, which might be a better choice if you want something more custom in terms of drawn controls, etc. |
Beta Was this translation helpful? Give feedback.
-
|
FWIW, for the template app Still curious as to why I'm glad that this thread was able to highlight though, that the support is good, and things are getting better all the time 👍 |
Beta Was this translation helpful? Give feedback.
-
If we didn't turn on all the knobs to maximize runtime performance for a release build people would be asking why... building with LLVM enabled is slow. Another point is that if the app isn't linked, there's a lot of code to AOT-compile (not sure if that's the case for your project, but enabling the linker will certainly make the build faster if you're not using the interpreter).
Note that the simulator is not supposed to be a complete replacement of a real device, there are known differences, both from Apple's side and ours. |
Beta Was this translation helpful? Give feedback.
-
|
@rolfbjarne Having a quick ganders at the binlogs... For publish release, about 50 dlls get passed to AOTCompile. When just building release there's around 200. I suspect the answer to the discrepancy in the times for release build (iossimulator-arm64) and release publish (ios-arm64) might have something to do with that. Perhaps that's one of the known and expected differences on the macios side like you say, but to me, seeing all those extra dependencies feels like a bug. Of course, I do appreciate and expect that there's going to be differences between a real device and the simulator, more the intent is to shake down side effects from constant defines etc. In an ideal world maybe I'd be paid more and just run device tests on a real device 😆 But it would be nice if one day build release ran as fast as publish release. I didn't mean for the slow build comment to be overly critical or contentious - thanks for the reply 👍 |
Beta Was this translation helpful? Give feedback.
-
|
I think this has been kind of fixed in .NET 10. There's some history here: for x64 in the simulator we don't need to AOT-compile anything (the JIT compiler works), and this makes simulator builds really fast - and as such the linker was disabled, because it would only slow things down. Unfortunately the JIT isn't an option for arm64 (due to limitations in the simulator itself), so we have to AOT compile at least some parts of the app, and if the interpreter is not enabled, then we have to AOT compile everything. This means that the default settings for a release simulator arm64 build (linker disabled, interpreter disabled, llvm enabled) would be slow (AOT compiling everything with llvm enabled). The default settings for a release device build (linker _enabled, interpreter disabled), is much faster, because there's much less code to AOT compile. In .NET 10 this will be fixed because we enabled the linker by default for arm64 simulator builds. You could also do this in your csproj: <PropertyGroup>
<MtouchLink>SdkOnly</MtouchLink>
</PropertyGroup>for device builds this wouldn't change anything (because it's already the default), while it would make simulator builds faster (because there would be less code to AOT compile). |
Beta Was this translation helpful? Give feedback.
-
|
Ahh, perfect. Thanks for the history lesson! I can confirm that brings the release build times into line with publish. |
Beta Was this translation helpful? Give feedback.
-
|
To complement my previous post I would like to refer to the publishing phase of a MAUI App. While publishing for Android is quite straightforward, there's lots of room for improvement in publishing for iOS mainly because the process is not streamlined and heavily depends on the version combination of Visual Studio, .NET workload and MacOS. Fortunately, there are active discussions in the developer community leading to official resolutions with every new release of Visual Studio and the experience can be greatly improved if the developer is well equiped (I recently bought a Mac Mini M4 (2024) and building and testing with the iOS simulators just became lightning fast). To cut a long story short, my app is now hapilly welcomed to the App Store but had had a difficult time with configuring the connection with the Mac and the iOS bundle signing settings and manually installing the correct .NET runtime version on the Mac. |
Beta Was this translation helpful? Give feedback.
-
|
I would recommend looking at building for release in a cloud service, like Azure DevOps. Very straight forward, secure storage for signing keys, and the free tier will almost certainly give you enough build minutes. I also use it for git and use it so much I pay for it. |
Beta Was this translation helpful? Give feedback.
-
|
I wanted to give a more considered response to this now I've been using MAUI for a while longer. I also want to preface it by saying I do still think things are generally pretty good - I could definitely recommend it for simpler apps. This is intended to be constructive (I'm even hoping some for some corrections and/or suggestions to deal with these things), it's easy to lose focus on the negatives, or to assign blame where things aren't really MAUI's fault. MAUI is obviously built on top of other technologies with their own issues, and the experience in using it is also affected by the wider ecosystem of runtimes, libraries and tooling etc. With that in mind, here's some things I wish I'd known before starting porting a relatively large (100 KLOC) project to MAUI in the hope that this is useful to other people and/or might influence efforts to address them. 1. No working/de-facto standard template for a device test runnerThere is a sample repo from: Big projects need unit tests and CI. It's great that there's the start of something, but last time I checked, it seemed like it wasn't useable out-of-the-box (and maybe that's changed since). There's also no support for MSTest, which might be surprising without knowing the history since they're both currently MS products. I ended up writing a custom device test runner since my existing repo is old and already had large numbers of tests against MSTest - that seemed easier than to add support to the upstream project or rewriting the tests. What would be really awesome would be some official NuGet packages where you could pick and choose some runners and a template project to get things up and running quickly. I expect that this will improve as MAUI matures - it's not a blocker, but I'd rather not be rolling my own. 2. No de-facto standard solution for benchmarkingBenchmarkDotNet is otherwise completely awesome, but this also involved writing a custom runner. My app is heavy on maths/shaders etc. and I need to know where the time is being spent. A sample app and/or template for benchmarking would be amazing. 3. Profiling doesn't work out-of-the-boxAnother app is required for scaffolding profiling. Shout out to the legendary @rolfbjarne and the dotnet diagnostics team for fixing the upstream issues I encountered really quickly. The MAUI wiki still needs updating though. Here's the secret sauce you currently need to get it working on Apple: dotnet/diagnostics#5529 (comment) 4. UIKit does not play nicely with othersiOS and Catalyst support are built on top of UIKit, so is subject to UIKit's design. If you want to change some colors of controls then that's OK. If you want to override something like the slider track height then it's much more difficult. A fair amount of stuff in UIKit requires overriding methods/methods to change their appearance/behaviour. MAUI does at least make it possible but, as a developer, you probably want to just set a value on a property - unfortunately that's not how UIKit works. 5. Catalyst is poorly supported by AppleThings on the iOS side are not too bad, the bindings have good coverage of the APIs and work pretty well. Catalyst on the other hand I've found has a whole bunch of quirks, bugs, performance and memory issues. I've provided repros in Swift to Apple to show that the problems are bugs in Catalyst and I've never had any response to any of them, even though I consider some of them to be quite serious. Others I know have given up on MAUI for this reason alone - and it's not even MAUI's fault. In the Apple world, the support experience appears to be much better for macOS and/or SwiftUI than they are for Catalyst and/or UIKit. Unfortunately, macOS obviously isn't available as a TFM for MAUI like it is for AvaloniaUI. 6. No mixed-mode debugging other than WindowsMost of the time the runtime will help you out and you'll get some managed exception you can work with to handle or fix a bug, and that's great. Sometimes crashes occur on the native side though. Mixed-mode debugging is really good on Windows, but it's not available on other platforms. 7. No IJW for non-Windows platformsIJW makes it so easy to consume C++ from dotnet on Windows, it's a real shame it's not available for other platforms. Likely you're stuck wrangling vcpkg, stubbing out some C functions and P/Invoking it, or hoping that some kind folk did it for you already in a NuGet package 😄 8. GC does not play nicely with ARCMy hottest take... I genuinely like dotnet and C# and there's advantages and disadvantages to both, but I think ARC is generally more suitable than GC for most developers - especially if you're in an interop situation like with MAUI. Care is needed in the appropriate places with weak references etc. to prevent leaks. Careless dependence on GC over deterministic disposal can lead to seemingly random crashes on the finalizer thread where it can be difficult for people to locate the cause. Coupled with no mixed-mode debugging, it's more painful than it otherwise could be. 9. Accessibility is work-in-progress/brokenDespite being low down on this list, this is a major one, possibly even a deal-breaker for whether you should choose to use MAUI or not. If you're a large company and want to sell in the EU, then you probably need to be compliant with the EAA. You'd probably expect that things like tabbing between controls would just work out-of-the-box. Unfortunately, keyboard navigation is essentially completely broken right now for iOS/Catalyst. I haven't found a sample app to show how to get it to work, and I haven't found a workaround. If you need to ship something today where you need that to work, then a different framework might be a better idea. I'd be super grateful if someone who knows more about MAUI and UIKit knows a way around this. I can get it to work in a sample XCode project OK. In MAUI I've tried things like overriding Fortunately, you can turn on a global setting for macOS to force app accessibility, and if you're a small company then you're also exempt from EAA compliance. So, you might be legally covered by one of those cases, but it's a terrible user experience on desktop nonetheless. IMHO and FWIW, this seems to be another area where SwiftUI is a lot better than UIKit. 10. WinUI 3 is problematicMAUI leverages WinUI 3 for the Windows implementation, so it inherits whatever limitations WinUI 3 has (good old WinForms is still better in a lot of ways that matter). It's slowly getting better, and MS are at least more responsive to bugs than Apple, but just a few examples: I could go on and on, but suffice to say, it leaves a lot to be desired. It's not been open sourced yet, so you can't go fix it yourself either. It's been a few years since I last looked at MAUI on Android, so I don't have any comments there. I don't really recall encountering any blocking and/or hairy issues - certainly nothing like the trouble on Catalyst. Looking to the future, it seems like Swift ABI and API projection support is improving with dotnet 10+ (slim bindings are already a lot easier with dotnet 9). Unfortunately, given how long the issues with Catalyst have been around and the general design of UIKit, I don't see the problems with that going away. I'm no Apple expert, and maybe it's just too much work and/or not feasible, but I'd love to at least think that transitioning to SwiftUI under the hood in a couple of years might have the potential to make things better. TLDR;Some problems are inherited (Catalyst/UIKit/WinUI/etc.). Despite those things, it still likely beats writing multiple apps - especially for small apps and teams. Fixing just a few of the underlying problems could make writing MAUI apps an absolute joy. Phew! That was a lot... hope that's useful to somebody! |
Beta Was this translation helpful? Give feedback.
-
I noticed this as well. Honestly, I'm a bit worried that there was no real update1 from Apple regarding Mac Catalyst on WWDC in recent years. Additionally, when I google for "Mac Catalyst" I get MAUI results which worries me even more. :) There is even this post. Perhaps @rolfbjarne would know more about the Mac Catalyst and if Apple fixes bugs silently or not. It's not my intention to make it sound negative. However, I do think Catalyst poorly supported by Apple is a fair assessment. Footnotes
|
Beta Was this translation helpful? Give feedback.
-
|
Apple certainly fixes bugs silently sometimes, I've filed issues that have ended up fixed and they haven't responded to them at all. As for Mac Catalyst, I don't know more than you've already found out yourselves, it doesn't seem like it has any kind of priority at Apple. It feels like an after thought most of the time, or even when something is apparently supported, it's by accident (CarPlay?). |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the replies! I'm at least glad to hear that I'm not the only one. In my mind, UIKit is a bit of a lemon, there's no reason I could think of that you would start a project today that chose UIKit over SwiftUI (except of course requiring an Objective-C ABI). It's not terribly surprising that UIKit would be effectively abandoned by Apple, and if you're not using UIKit then there doesn't seem much point in Catalyst either. Unfortunately, that still means that a macos TFM paired with Swift ABI support in dotnet and a SwiftUI backend is the only course of action I can think of that would salvage things for MAUI on Apple desktop for non-trivial apps. As a bonus, it should fix the accessibility problems too. Again, not MAUI's fault - I place the blame squarely on Apple, but we are where we are. |
Beta Was this translation helpful? Give feedback.
-
|
@molesmoke If you're stuck you can capture keys (Tab) on iOS/Mac and focus the appropriate control, or switch tabs etc. Awesome post btw. |
Beta Was this translation helpful? Give feedback.
-
|
I should have mentioned that the root cause of the issue is that controls like UIButtons can't become focused by default in the first place in UIKit. Rendering the focus effect already works for other controls in the visual tree, so I assume it likely works if the underlying issue is resolved. |
Beta Was this translation helpful? Give feedback.
-
|
Ooooh..... If I implement it via a slim binding then it works!!!! It seems that the following are not equivalent: @objc(FocusableUIButton)
public class FocusableUIButton : UIButton
{
override public var canBecomeFocused: Bool {
return true
}
...
}public class FocusableUIButton : UIButton
{
[Export("canBecomeFocused")]
public override bool CanBecomeFocused => true;
...
}@rolfbjarne You're the only person I can think of to ask why? And if the difference in behavior represents an issue in the macios bindings or whether I did it wrong? Either way, this fixes a pretty significant problem for desktop use. |
Beta Was this translation helpful? Give feedback.
-
|
@molesmoke that's surprising... if you have a test project, I can have a look and figure out the difference. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the offer 👍 The answer seems to be that you need to override CanBecomeFocused and use the parameterless constructor. I can post a repro early next week, but it's a bit too late in the day here. I note in the macios bindings, the UIButton.ButtonType convenience init is exposed as a regular constructor (which is what MAUI uses). Would that be a problem? i.e. Should that it be static perhaps? I'm no Apple/Swift expert but I thought a subclass could only call the designated initializers, so I'm not sure how that works. At least I can make it work in pure C# though, so that's something! |
Beta Was this translation helpful? Give feedback.
-
|
Yes, UIButton is a bit special, in that the UIButtonType constructor shouldn't be used when subclassing UIButton: |
Beta Was this translation helpful? Give feedback.
and others
Uh oh!
There was an error while loading. Please reload this page.
-
Many older discussions stem from the rocky transition period of the past few years. But what’s MAUI’s current state?
I work with MvvmCross but am considering making a relatively simple MAUI app, without much media or other UI-heavy tasks.
Side question: Is Rider’s support for MAUI any good?
Beta Was this translation helpful? Give feedback.
All reactions