More Maui Internals Should Be Marked Public

[Axemasta]

I was recently porting the work over in the Community Toolkit's TouchEffect branch since I wanted to use it before it releases. I noticed that some of the platform code in that implementation was referencing maui internals. Looking into the maui codebase, there are InternalsVisibleTo attributes set for the Community Toolkit:

Whilst I support this decision for the Toolkit, in Xamarin it delivered mission critical components & tooling essential for building Xamarin apps (you could argue alot of XCT belonged in Forms). This highlights a design issue Xamarin had & Maui has inherited, alot of the platform components are sealed away and are extremely difficult to port / implement outside of the Maui codebase.

When the need arises to override / implement extremely custom behaviour, because lots of helpers and internals are hidden away from the public devs are forced down 2 paths:

• Copy Maui code until everything works (this can be an extremely long rabbit hole)
• Use reflection to call underlying maui framework methods at runtime (annoying to code, bad performance and linker unsafe)

I personally had this issue in Xamarin when I made my SuperWebView control, a rewrite of the WebViewRenderer that fixed a Xamarin framework bug (yes its still here in Maui). If you read the code I had to copy lots from Forms (all internals) to make the new renderer implementation work correctly. Its extremely frustrating from a developer perspective when Forms/Maui gets in the way of me implementing some custom feature or I can 't easily override Maui behaviour.

Back on topic, if Community Toolkit is allowed access to Maui internals due to needing to reference them for platform implementations, everyone needs access to these internals and they should be opened up in future maui releases.

[jonmdev]

I agree with you whole heartedly. I have absolutely no idea why an "open source" project has ANY classes marked "internal." It is absurd.

What is the rationale? Do they think we are too stupid to use the code correctly? If someone wants to build a broken MAUI app by making bad decisions, they can do it either way. I have no idea what benefit is served by forcing us to use reflection to access these "internal" methods and classes.

I have never had to do this so I don't know how practical it would be, but what would happen if one forked MAUI or downloaded a copy and just did a find and replace on every "internal" reference inside it to make it "public"?

Would you have to build it as a project into dll or other files? Or could you even just drop that into a folder in your project and have it work somehow? Remove the MAUI dependencies and just use that instead?

I wonder if that would work or be easier than having to work around reflection code when it comes time for obfuscation. One could just periodically re-download the whole MAUI project and find replace it to work from instead. What would be the harm?

What do you think? Would that work?

[Dreamescaper]

Rationale is that there is a public surface, which maintainers should prevent from breaking changes. Internal APIs could be changed at any moment without any communication.

[jonmdev]

Oh I never thought of it like that. Makes sense. I get the idea behind it now.