Please make XamlLoader Public

Summary

Please make the class "XamlLoader" public. It is found in the namespace Xamarin.Forms.Xaml. https://github.com/xamarin/Xamarin.Forms/blob/master/Xamarin.Forms.Xaml/XamlLoader.cs

Or...

Make the "LoadFromXaml" method in Xamarin.Forms.Xaml.Extensions public.

One of these is required to dynamically load UI from Xaml at runtime.

API Changes

Please make this class public:
https://github.com/xamarin/Xamarin.Forms/blob/master/Xamarin.Forms.Xaml/XamlLoader.cs

Or...

Make the "LoadFromXaml" method in Xamarin.Forms.Xaml.Extensions public.

Intended Use Case

We will be storing Xamarin Forms Xaml in our database. We will be dynamically loading this Xaml in to the UI at runtime. We have already proved that we can use the "LoadFromXaml" method in Xamarin.Forms.Xaml.Extensions to achieve this through reflection. However, the method is not currently public. We need to load UI dynamically from Xaml at runtime. No ifs, not buts. This is an absolute, and unwavering requirement. If Xamarin Forms cannot do this, the technology can not be used to achieve our goals.

I started this thread here:
https://forums.xamarin.com/discussion/comment/249796#Comment_249796

People all over the web are requesting the same thing: that UI be loaded dynamically from Xaml. Our Silverlight product is based heavily on dynamically loaded UI being loaded from Xaml, and we wish to continue this paradigm. There appears to be no impediment to making the method to load UI from Xaml a public method. Here is an article about this: http://www.cazzulino.com/dynamic-forms.html.

So, please make these APIs public so that there is no need for a work around. If there is a strong reason not to make them public, please explain why this is the case. If there is a strong reason not to make it public, we need to know now so that we do not go too far down the path of building our solution around this workaround.

Tagged:

Rejected · Last Updated

Posts

  • MarkRadcliffeMarkRadcliffe NZMember ✭✭✭

    I can see this being useful for white labelled applications like my own to offer more specific customisation, however there is a performance reduction using non compiled xaml. If there is a way to pre-render a xaml file in a background thread and reused that "pre-rendered view" that could be interesting.

    i.e. provide the xaml to a pre-renderer which parses the xaml as a view that can be reused in some way (i.e the binding context will change).

    Question to the op, how would this work from the initialisation? I Assume you will manage the data context binding to be added during navigation or something? are you doing dynamic xaml controls, views or both?

  • MelbourneDeveloperMelbourneDeveloper AUMember ✭✭✭
    edited February 2017

    @MarkRadcliffe said:
    there is a performance reduction using non compiled xaml.

    Please... for the love of God, do not turn this in to a debate. Everyone is entitled to their opinion, and if you believe that the performance hit is too problematic, then by all means, feel free not to use dynamic loading of UI with Xaml. For my two cents, there may or may not be a performance hit, but this performance hit is irrelevant considering the massive benefits that come along with storing your UI in the database. The bottom line is that people are welcome to build apps however they want. In our case, we have no choice. We have to dynamically load UI based on Xaml. That Xaml absolutely must be stored in the database. Our entire infrastructure works this way in Silverlight. It always has, and is the core strength of our system.

    @MarkRadcliffe said:
    how would this work from the initialisation? [...] I Assume you will manage the data context binding to be added during navigation or something?

    All data binding will be done at the Xaml level so that data binding is configured in the database and not hard coded in to the application. But yes, you are right, the navigation engine will manage the BindingContext. We have already shared the code across Silverlight and Xamarin Forms so that the engine for swapping in the BindingContext is the same between the two platforms.

  • StephaneDelcroixStephaneDelcroix USInsider, Beta ✭✭✭✭

    It's not a debate. This might affect the performances in your application, and that will hurt the platform reputation

  • IrrealIrreal RSUniversity ✭✭✭

    Oh wow, it might affect performance and that will hurt platform reputation? Surely you are not serious?
    Anything misused will affect performance. Why not throw an exception in the xaml compiler as soon as nesting reaches 4 levels deep? That too will affect performance and "hurt platform reputation".

    Why is Xaml compilation opt-int/opt-out then? Are you planning on making it mandatory?

    That's just a silly stance. You can not stop inexperienced or rushed developers from misusing your platform and your platform reputation should not stand on what the worst or even the average developers do with it, as long as the best ones are able to use it in a powerful way, the reputation should be good.

    This feature is very powerful when used sparingly and optimally. I vote to make it public.

  • MarkRadcliffeMarkRadcliffe NZMember ✭✭✭

    Please... for the love of God, do not turn this in to a debate. Everyone is entitled to their opinion, and if you believe that the performance hit is too problematic, then by all means, feel free not to use dynamic loading of UI with Xaml. For my two cents, there may or may not be a performance hit, but this performance hit is irrelevant considering the massive benefits that come along with storing your UI in the database. The bottom line is that people are welcome to build apps however they want. In our case, we have no choice. We have to dynamically load UI based on Xaml. That Xaml absolutely must be stored in the database. Our entire infrastructure works this way in Silverlight. It always has, and is the core strength of our system.

    Settle down, I was not starting a debate, I was stating the obvious implications of running dynamic Xaml, and that is a performance hit on complex views, it slows down page load otherwise why would they have bothered with a precompilation system? And for when that performance impact is problematic offering a possible solution (i.e. expanding your idea). When did I say that you shouldn't do any of this? Maybe take the carrot out of your ..? if you want people to take you seriously.

    In general I like this idea as I can see it being useful for my apps too, as everything is white labelled and configurable. But it would be nice to have something that allows prerender of the dynamic content for more complex views.

    Can the work around currently render full views AND controls (i.e. a view cell)?

    This could also be done using JSON in some instances rather than Xaml but that wouldn't be as ideal.

  • MelbourneDeveloperMelbourneDeveloper AUMember ✭✭✭
    edited February 2017

    @MarkRadcliffe

    I didn't want this to degrade in to what you are dragging this in to, but your point is mute anyway. You obviously don't understand how Xaml works. There is no performance hit anyway. You can view the code here: https://github.com/xamarin/Xamarin.Forms/blob/master/Xamarin.Forms.Xaml/XamlLoader.cs . Regardless of whether you compile the Xaml files in to resources in your project, or the Xaml is passed in from some other source via the LoadFromXaml method, the Xaml is still parsed at runtime. I think that's where you're getting confused. You think that Visual/Xamarin Studio magically does this work for the app before the app is run. This is not correct. That is only the case if you use XAML Compilation. The Xaml is parsed at runtime, and the code behinds merely traverse the visual tree of controls to find the objects for the variable names. The code behinds actually call the same method LoadFromXaml that I am referring to.

    @StephaneDelcroix, and @MarkRadcliffe, can I assume that you are using XAML Compilation for all of your Xamarin Forms (https://developer.xamarin.com/guides/xamarin-forms/xaml/xamlc/)? Would you will it that all Xamarin Forms programmers be forced to use this feature for all forms? If not, then you've misunderstood something.

    So please, if you don't want to use the feature, don't use it. Meanwhile, others are in need of the feature.

    Even if this does cause some kind of performance hit, I want to hear it from the horse's mouth - the Xamarin Forms Team. If performance is the reason why this method has not been exposed publicly, could the Xamarin Forms Team please explain this?

    I also second @Irreal 's comments.

    @Irreal said:
    Oh wow, it might affect performance and that will hurt platform reputation? Surely you are not serious?
    Anything misused will affect performance.

    Whenever someone builds an application, the onus is on that programmer to pay attention to performance. A programmer who does not pay attention to performance on a good platform will write a slow, non-responsive app. A programmer that pays attention to detail can make the best of performance even when the platform is designed poorly in this respect. Any platform's features can be misused to make performance poor. I am telling you clearly here that dynamically loading Xaml at run time - with the use of the methods I am referring to is not a performance issue. I've tested it. It works, and it does not cause a degradation of performance in any meaningful way.

    So, the request if for the method(s) to be made public and to be fully supported by the Xamarin Forms Team. If there is some reason for this not happen, I'd like to know why.

  • MelbourneDeveloperMelbourneDeveloper AUMember ✭✭✭

    Is there a chance anyone from the Xamarin Forms team could provide some information on the status of this? We are running with the reflection hack. If there's a reason we should not be doing this, we want to know about this now rather than later. If it turns out that this feature will never be directly supported, we need to know about this.

  • LmontekLmontek RUMember ✭✭

    I vote to make it public!

  • MelbourneDeveloperMelbourneDeveloper AUMember ✭✭✭
    edited February 2017

    Yes. Has the Xamarin Forms team got anything to say about this?

    Could we at least get a word or two on why this hasn't been made public yet?

  • ChaseFlorellChaseFlorell CAInsider, University mod
    edited February 2017

    @MelbourneDeveloper said:
    Yes. Has the Xamarin Forms team got anything to say about this?

    Could we at least get a word or two on why this hasn't been made public yet?

    @StephaneDelcroix is the one responsible for what XAML in Xamarin Forms is today. Take note when he chimes in.

  • MelbourneDeveloperMelbourneDeveloper AUMember ✭✭✭

    Thanks @ChaseFlorell

    You mean responsible for XAML inside Xamarin Forms? Or, you mean literally the entire technology?

  • ChaseFlorellChaseFlorell CAInsider, University mod

    @MelbourneDeveloper said:
    Thanks @ChaseFlorell

    You mean responsible for XAML inside Xamarin Forms? Or, you mean literally the entire technology?

    right, in Xamarin Forms... I'll edit.

  • MelbourneDeveloperMelbourneDeveloper AUMember ✭✭✭

    @StephaneDelcroix , if I could get a word in quickly...

    We've been powering forward with sharing our UI engine across Silverlight and Xamarin Forms. With the use of the hack that I've mentioned previously, we are well on our way to being able to dynamically load a customer's UI at runtime from the database. I've tested this and dynamically loading the Xaml works really well. Even binding works correctly.

    If this method isn't made public, we'll have to go with the hack that I've implemented because this isn't an option for us. The customer's UI needs to be stored in the database because each customer has a different set of screens and customization in our software.

    So, I'm begging you to make the method public and allow it be fully supported. However, if there is a devastating reason as to why we shouldn't be using dynamic loading of Xaml, I'll listen and evaluate what you say.

  • ChaseFlorellChaseFlorell CAInsider, University mod

    @MelbourneDeveloper are you able to create your custom fork and open it up for your needs? I do see Stephane's point about performance.

  • MelbourneDeveloperMelbourneDeveloper AUMember ✭✭✭
    edited February 2017

    @ChaseFlorell , you see Stephane's point? How, in your opinion do you think that this would impact performance?

  • TobiasSchulz.9796TobiasSchulz.9796 DEMember ✭✭
    edited February 2017

    Well obviously, Xaml Compilation is the future and is to be preferred by almost everyone, because of performance reasons. When it reaches full feature partity, it can be enabled by default and every app will benefit from it, except yours - yours will break because it requires the dynamic loading, which will become obsolete. And for many people, it already is obsolete as xamlc it already so much better.

    I understand your platform works the way it does, but that doesn't necessarily mean that your goals are future-proof if dynamic loading is not the way Xaml is going to go.

    BTW, our company is doing something very similar, but based on JSON. I recommend you grab the source code and package your own Xaml loader (independent of Xamarin.Forms), that's really not a complicated task since everything is open source. Or, maybe do your own UI format and load it at runtime.

    I think that for most use cases, Xaml Compilation is the future and I can understand it very well if Xamarin doesn't want to support dynamic xaml loading in the long term.

  • gahmsgahms DKMember

    We have another use case for this: We are defining styles (e.g. colors) in App.xaml and use them, among other places, in our view models. For those view models we have unit tests and we would like to be able to load the definitions in the unit tests.

  • DavidDancyDavidDancy AUMember ✭✭✭✭

    @gahms Isn't that what ValueConverters are for? I'm curious how a color can be useful in a ViewModel.

  • MelbourneDeveloperMelbourneDeveloper AUMember ✭✭✭
    edited February 2017

    @TobiasSchulz.9796

    Well obviously, Xaml Compilation is the future and is to be preferred by almost everyone, because of performance reasons

    Not obviously. Performance optimization is always a consideration in app development. When there's a clear performance benefit from using some feature, it's usually worthwhile implementing it. In regards to dynamic loading of Xaml, there's no clear performance hit from parsing the Xaml at runtime. If it's really that important to you, I could make some objective measurements of time to expose exactly how long it takes. But, I can tell you that it's nothing that that is noticeable at the user experience level.

    Saying that though - I am open to looking in to compiled Xaml. I'm not sure if compiled Xaml will ever have the full feature set of runtime parsed Xaml, but assuming it does, I'd be interested in using it.

    The problem with compiled Xaml though - is the overhead of having to precompile the Xaml in to physical DLLs, and then somehow have those DLLs be dynamically loaded at runtime. We are talking about store apps here. So, if each customer has a different UI, they Xaml will need to be compiled in to separate DLLs for each customer. And, I'd have to create a tool which handles compiling to DLLs, and deploying those DLLs to some place where they can be grabbed by the app at runtime. At this point, I'm not even sure if that is possible on all the different platforms. I have not tested this yet, and I know that Apple are very strict about security so I am not sure if the iOS platforms will allow us to dynamically load DLLs at runtime.

    The other option of having a different store app for each customer is completely out of the question...

    Note: @TobiasSchulz.9796 - that as yet - it seems that it is not possible to load assemblies dynamically at runtime, so your point is moot unless there has been some change in the framework recently.
    https://forums.xamarin.com/discussion/2294/assembly-load-is-it-possible

    @gahms

    We have another use case for this: We are defining styles (e.g. colors)

    This is another typical use case for dynamically loaded Xaml.

    So, anyway, to recap - Xaml compiled Xaml may be an option in the future as long as it is possible to implement properly. Perhaps someone could tell me how easy it is to dynamically load DLLs at runtime on all the platforms. But, for now, we need this method public. We are already using the method and it is not a performance hit for what we are doing.

    If the Xamarin Forms team has an opinion on this topic, I'd really like to hear it.

  • MelbourneDeveloperMelbourneDeveloper AUMember ✭✭✭

    @DavidDancy - ValueConverters can be part of the solution - but only part of.

    A lot of people that use Xamarin Forms aren't used to the raw power that Xaml can provide. If you come from a Silverlight/WPF/UWP background, you can see that styling can be stored in the database on a customer by customer basis. This is easy to achieve on those platforms. This is part of the reason why I'm pushing for this to be done. If the method for parsing Xaml were made public, styles could be easily applied at runtime like the other platforms, and there would be no need to write ValueConverters in to the binding of each piece of Xaml.

  • DavidDancyDavidDancy AUMember ✭✭✭✭

    @MelbourneDeveloper I've handled this scenario slightly differently than you, I think. We have an app that we've turned into a white-label offering that can be re-skinned for different clients. In addition we offer customisations that go beyond simple changes of colour and font.

    To achieve this I've made use of the DI container. It happens that we use FreshMvvm as our tool to automatically connect a ViewModel to each of our Views, but any DI container should work.

    Normally, the FreshMvvm system constructs a Page to match the PageModel (aka ViewModel) that we're navigating to by using a naming convention and reflection to find the right pieces. However I can override this mechanism by registering in the DI container client customised Page/PageModel pairs that I want to use instead of my "stock" Page/PageModel pairs. These customisations I typically put into a project (DLL) of their own, one per client.

    The end result is that all the code for all interfaces can be built at compile time, and we use all the facilities of the IDE for designing the UI. We can take advantage of XamlC and the only runtime hit is loading things into the DI container and finding them there when they're needed. There's no dynamic XAML loading, and no need for it either. Plus the linker can get rid of stuff we don't use.

    I'm not saying that dynamic XAML loading wouldn't be useful - just that we found a different way of achieving the same end result without needing it.

  • MelbourneDeveloperMelbourneDeveloper AUMember ✭✭✭
    edited February 2017

    @DavidDancy said:

    I've handled this scenario slightly differently than you
    These customisations I typically put into a project (DLL) of their own, one per client.
    The end result is that all the code for all interfaces can be built at compile time, and we use all the facilities of the IDE for designing the UI. We can take advantage of XamlC and the only runtime hit is loading things into the DI container and finding them there when they're needed. There's no dynamic XAML loading, and no need for it either.
    I'm not saying that dynamic XAML loading wouldn't be useful - just that we found a different way of achieving the same end result without needing it.

    This doesn't sound like a bad solution. But, I have to ask the obvious question. How are you managing these customizations? Are you compiling every single customer's customized UI in to the same projects, and deploying all that to all your customers? Or, are you doing selective builds with a different physical app package for each customer?

  • DavidDancyDavidDancy AUMember ✭✭✭✭

    @MelbourneDeveloper selective builds, one per customer. My solution file is pretty unwieldy (I have a v2 solution that's a bit better, and has to rely on build scripts to adjust things like bundle ids / provisioning profiles and the like) but I can build a client's app with full XamlC on everything, and all they get is what applies to them. There's a core DLL that contains the AppDelegate / MainActivity plus all the functionality that applies to all the clients; but then with the custom DLLs I can provide whole screens and extra functionality for individual clients without affecting anyone else. I kind of fell into it but I'm now working on a template that will enable me to rubber-stamp the solution structure for new apps too.

  • MelbourneDeveloperMelbourneDeveloper AUMember ✭✭✭
    edited February 2017

    @DavidDancy said:
    @MelbourneDeveloper selective builds, one per customer. My solution file is pretty unwieldy (I have a v2 solution that's a bit better, and has to rely on build scripts to adjust things like bundle ids / provisioning profiles and the like) but I can build a client's app with full XamlC on everything, and all they get is what applies to them. There's a core DLL that contains the AppDelegate / MainActivity plus all the functionality that applies to all the clients; but then with the custom DLLs I can provide whole screens and extra functionality for individual clients without affecting anyone else. I kind of fell into it but I'm now working on a template that will enable me to rubber-stamp the solution structure for new apps too.

    How many customers do you have? We have at least 10 and we are gaining more all the time. That means at least 30 apps (Android, iOS, UWP) in the app store to maintain. How do you manage this?

  • MelbourneDeveloperMelbourneDeveloper AUMember ✭✭✭
    edited February 2017

    Xamarin Forms Team, @StephaneDelcroix

    Could you please chime in on this? I agree that compiled Xaml is a great concept. But, the point is that we need to load Xaml dynamically at runtime. I'm happy to look in to pre-compiling Xaml, but if that's what we've got to do, then we're going to need dynamic loading of assemblies at runtime which becomes a totally different feature request that may not even be feasible because of Apple's strict security policies (No Emit)

    Could you please indicate one way or the other what your recommendations are, and where you think the technology will head in the future?

  • DavidDancyDavidDancy AUMember ✭✭✭✭

    @MelbourneDeveloper I fear we may be getting off-topic :smile:

    Happy to discuss in a new thread if it suits. Shall I start it or will you?

  • DavidDancyDavidDancy AUMember ✭✭✭✭

    @MelbourneDeveloper our solution doesn't involve dynamic loading of DLLs. Everything is compiled and the only runtime mechanism is to register custom pages / functionality in the DI container.

  • MelbourneDeveloperMelbourneDeveloper AUMember ✭✭✭

    @DavidDancy

    Understood. The question is how this is managed...

    Do you have a separate app for each customer in each app store?

  • DavidDancyDavidDancy AUMember ✭✭✭✭

    @MelbourneDeveloper Yes we do. Our customers create their own Apple / Google developer accounts, and then make us admins of those accounts so we can publish on their behalf. Then we manage the whole of the rest of the process for them.

  • MelbourneDeveloperMelbourneDeveloper AUMember ✭✭✭
    edited February 2017

    @DavidDancy , how many customers in how many stores do you manage? How often are UI changes made? Doesn't this become unwieldy?

    We have about 10 customers who will want to have apps in several stores. That number is growing. We have periods where the UI changes on a daily basis as we fine tune the UI based on constant feedback from the users. Redeploying to all those app stores would be an absolutely massive overhead for us, and it would also discourage us from making small tweaks to the UI at the drop of a hat.

    For example, currently, if a user says that a scrollbar is too thin to use in a touch environment, we tweak the Xaml in one spot, and then the scrollbar width is rolled out to all users instantly without needing to redeploy anything. This is the whole point that I am getting at. There is no reason why this can't be done with Xamarin Forms. Xamarin Forms has this feature built in. It's just not made public for some reason that has yet to be established.

  • DavidDancyDavidDancy AUMember ✭✭✭✭

    @MelbourneDeveloper I can see that your scenario pretty much demands the use of dynamic XAML. We're a bit more static than that with nowhere near as many UI updates. In addition although it's a white-label app we don't (yet) release updates of the app to all clients at the same time. Your update loop would be much longer with our way of doing things as you'd have to wait for app store approval all the time. So your solution is a great way to short-circuit that process.

  • MelbourneDeveloperMelbourneDeveloper AUMember ✭✭✭

    @DavidDancy , thankyou.

    I wish that I worked in an environment where we could deploy an app to a several customers at once and expect that the UI not change until the next release. However, this is the not the reality of our industry. Our customers expect change quickly, and not just in the development phase. They demand that the UI be tweaked at the drop of the hat, and this has been our core strength in our industry. Our customers are tired of vendors that promise that they can customise the application for them, but then charge $10,000+ to change a label or whatever. We regularly add fields, or entire panels of fields on the fly during production usage. This is one of the reasons our customers remain loyal - because we are able to deliver a truly tailored solution without maintaining 10 different branches of code. What we deliver to our customers is the ability to fine tune UI as the needs of the business changes, and without app redeployment.

    This may not be a requirement for every development house, but this is certainly a requirement for us. And so, we need this method made public.

  • MarkRadcliffeMarkRadcliffe NZMember ✭✭✭

    @MelbourneDeveloper - I have done quite a bit of white labelling and customisation of views but use Json to do it. It could make sense to do this using dynamic xaml or Json for your views and styles. You wouldn't be able to do any viewmodel alterations though so I guess you'd have to have this as a backend service with a URL link to get a view model each time.

    Have you thought about automating you deployment process anyway using something like visual studio team services which let you deploy on checkin for instance to each of the stores? A mixture of that and dynamic content may still work well. Static with auto deployment where performance is a requirement and dynamic where it isn't. It'd still be really good if they were able to have a mechanism for pre-compiling dynamic views in a background thread so they are pre-readied for when its needed.

  • MelbourneDeveloperMelbourneDeveloper AUMember ✭✭✭
    edited February 2017

    @MarkRadcliffe , I don't understand your point. What are you suggesting I do?

    I'm hearing lots of people suggesting that Xaml be compiled in to DLLs and then be included as part of a special build. I hear these suggestions, but the whole point of this feature request is to not have to do that. The whole point of this feature request is to be able to store the UI in the database as opposed to compiling DLLs.

    In our existing app, we save Xaml in to the database. As soon as the record has been saved, every single user gets the change. There's no need to recompile or redeploy. The benefits of this should be obvious, but somehow the message is being lost here...

    If it turns out that dynamic parsing of Xaml at runtime is too much of a performance hit, pre-compiled Xaml is an option. But, my tests simply do not show this to be the case, and phones are getting faster and faster every day. The point is that maintaining UI in a DLL is onerous and requires extra maintenance from the configuration team. Perhaps it could be done, but why? The existing method LoadFromXaml works well, and doesn't cause performance problems.

    Pre-compiling Xaml in to a DLL is like trying to swat a fly with a sledge hammer.

  • gahmsgahms DKMember

    @DavidDancy said:
    @gahms Isn't that what ValueConverters are for? I'm curious how a color can be useful in a ViewModel.

    That is one way to resolve it, yes. It will introduce an extra level of abstraction between what the ViewModel decides and what will be shown on screen. The styles from App.xaml are what I see as the necessary abstraction between what the ViewModel decides (e.g. "CompanySecondaryLightColor") and what should be shown on the screen (e.g. Color.FromHex("123456")).

    That same abstraction ("CompanySecondaryLightColor") is also used in the various views (xaml).

    If I add a ValueConverter I will get another level of indirection that (in my opinion) does not add any value. Actually I think it adds unnecessarily to the complexity and readability of the xaml.

    One of the great forces of Xamarin.Forms compared to, say MVVMCross, is that you can have this kind of stuff in the ViewModel.

  • MelbourneDeveloperMelbourneDeveloper AUMember ✭✭✭
    edited February 2017

    Are we going to hear anything from the Xamarin Forms team on this?

    Anything at all?

    Why are you being so reticent? You've built this technology. The ability to dynamically load UI components with Xaml exists and it's a great feature. If you're not planning on making the feature public, why don't you clear up your reasons?

  • DavidOrtinauDavidOrtinau USForum Administrator, Xamarin Team, Insider, University Xamurai

    @MelbourneDeveloper we’ve been monitoring the discussion and seeing where the conversation went. It sounds like several people commenting on this thread have offered some other reasonable solutions to achieve your goals, and I hope those prove fruitful for your situation. At this point the discussion appears to have run its course.

    We are not going to make it public. It comes down to stability and performance. We continue to hear this mandate loud and clear from the community.

    We have been making great improvements with XAMLC which is getting us further down the path of resolving bugs and improving performance. Supporting both runtime XAML loading and compiled XAML is effectively 2 frontends to the XAML engine. We are investing in the latter.

    A bit of advice for anyone putting forth proposals:

    We need to load UI dynamically from Xaml at runtime. No ifs, not buts. This is an absolute, and unwavering requirement. If Xamarin Forms cannot do this, the technology can not be used to achieve our goals.

    From the beginning, this proposal was positioned as inflexible and the tone of the comments that followed demonstrated that healthy discussion would be difficult. If you want to engage people and win them to your point of view, lay out your goals and vision and embrace discussion from other viewpoints. You’ll win more advocates this way.

This discussion has been closed.