Multiple apps with same shared code base

[ota-ash]

Hi:
I have multiple apps 4 iOS and 4 android, which was configured under Xamarin forms.
Now that I'm migrating to Maui, how can I get multiple apps (IOS and Android) organized under Maui to get same end result?
For example: I have App1.iOS, App1.Android, then App2.iOS and App2.Android. They all share the same code base, but with different assets and some different properties defined at runtime.
What is a best way to organize a project structure like this? Are there any samples?

[abdul-wasey]

Hi @ota-ash do you find any solution for this ?

[JoeVoo]

have a look:
https://blog.ewers-peters.de/white-labeling-net-maui-apps

[abdul-wasey]

@JoeVoo the link you shared, It not working for me.
Could you please check ?

[JoeVoo]

now it's working

[TrueMoniker]

I would recommend setting up your solution similar to any .NET soluton with multiple projects. The trick is to have a different project in the solution for each of your applications, and different projects for any of your shared code.
One difference between Xamarin and Maui is you don't need to separate projects for iOS and Android. Both of them are kept in a single project and the OS is selected at compile time.

For example you might have
YourSolution.sln
{
- App1.csproj (runtime),
- App2.csproj (runtime),
- Models.csproj (shared),
- Controls.csproj (shared)
}
Your runtime projects would reference your shared projects.

In your runtime projects, you'll want to keep your MauiProgram.cs file, as well as your Platforms folder and platform specific resources.
Anything else can be loaded from a shared project if you would like.

I have a few recommendations to keep in mind when setting up your projects

1. Be very careful about circular references. A good rule of thumb is nothing should reference your runtime project. If something is, you probably need to move what is being referenced into a shared project. I keep a separate project just for interfaces that references nothing. Then I have services that implement my interfaces and resolve those interfaces from the dependency container. This has saved me from several circular reference conflicts, though I admit it's a bit of a hack.
2. Keep in mind issue 16468 - if you only use a resource in xaml and not c#, the linker may strip it out. So if you find you are getting a missing reference error for a property you are certain you are loading, check if it is only being referenced in your xaml.