Quick Links

Xamarin.Forms Feature Roadmap

Posts

@TonyD please raise that conversation on the Let's Talk Performance thread. Layout Compression and Fast Renderers are intended to address the layers of nesting, additional views.

To all, let's please keep the conversation here on the feature roadmap. For follow up on specific issues, bug reports, or for general feedback you can certainly always email me [email protected], or find the appropriate thread to discuss it such as the performance thread linked above.

It will also lead to a revival of the native look and feel discussions that plagued Swing.

Eric from the google flutter team pointed out (in a i/O presentation) that whole native control focus does not seem to have the same relevance anymore, since the award-winning apps employs heavily customised UI anyway. That makes sense.

If we actually look at what customers want, they couldn't care less about native controls. They do however, want smooth, fast, and robust UI/UX that excites and delights them. Flutter is on the path to deliver just that.

However, I generally agree with you. The current implementation is too ambitious and too prone to bugs.
You can almost say it's the nature of the beast.

Indeed. It's like building a house on a Glacier : "Hmm. That crack wasn't there yesterday"

I just don't think it can be sustained in the long term.

I agree. A combination of flutter-like widgets, need-to-have native renders and embedding in platform UI might hit the right spot for most projects. I don't have the complete solution

@void said:
Eric from the google flutter team pointed out (in a i/O presentation) that whole native control focus does not seem to have the same relevance anymore, since the award-winning apps employs heavily customised UI anyway. That makes sense.

Can you point to the presentation where he says this?

I think customers obviously do not care or know what does "native" means nor if your app is "native" or not. I can definitely agree with that. But if your app is slow and clunky of if it tries but fails to mimic the native UI, that's a problem.
If your app has a crazy look and shares same crazy look on both Android and iOS, I might agree building it with the approach you suggest might make sense. But there might be some small details which could make that approach not the best.

And in regards with using Flutter (funny name): I would not use Flutter unless for very quick and very small prototype projects.

@void said:
Eric from the google flutter team pointed out (in a i/O presentation) that whole native control focus does not seem to have the same relevance anymore, since the award-winning apps employs heavily customised UI anyway. That makes sense.

Can you point to the presentation where he says this?

I think it is acknowledged here: from around 9:15 - 11:00'ish but watch the entire 24 min. to get a feel for the principles. The video is from 2016.

@DavidOrtinau I think the message you should be taking away from many of the posts here is that there are a lot of very dedicated, and supportive developers using Xamarin.Forms who think the dev team has done an amazing job with the resources they have available and passionately believe in the product, but who are very, very frustrated.

We are frustrated because we don’t see the emphasis on making the product truly industrial strength. There are a lot of words spoken (written), but talk is cheap and we are not seeing the results. You claim there is an emphasis on quality and bug fixes, but our experience is different.

Please, help persuade the powers that be to postpone new features in favour of improving what is there. The focus of 3.0 is wrong. The performance improvements are a band aid, the layout engine needs to be re-architected - Jason Smith has said as much in the past. That should have been the focus of 3.0, but of course it’s not sexy and I'm sure that there was pressure from Microsoft to add new features that could be marketed with fanfares. It would not surprise me if Jason and his core team are frustrated by not being allowed to do the re-architecting that they have previously expressed a need for.

Xamarin and Microsoft should be looking over their shoulders at NativeScript and React.Native as real competitors for Xamarin.Forms and not get complacent about performance and stability. They are the key to the future, not new features.

@void
That demo at 11:25 mark, the speed it loads is so awesome. A Xamarin Forms app is so clunky today.

@DavidAllen said:
We are frustrated because we don’t see the emphasis on making the product truly industrial strength. There are a lot of words spoken (written), but talk is cheap and we are not seeing the results. You claim there is an emphasis on quality and bug fixes, but our experience is different.

THIS!
After 3 years after it was released, Xamarin Forms is still clunky and buggy on Android and iOS, the mobile platforms which actually represent what mobile is today and many years to come.

Also, the Xamarin Forms XAML Previewer is still not fully functional. It's an essential tool. Just the other day I saw yet another tool, a XAML Previewer, but which is a commercial product. This is a simple sign that after 3 years something is wrong with Xamarin Forms.

Please, help persuade the powers that be to postpone new features in favour of improving what is there. The focus of 3.0 is wrong. The performance improvements are a band aid, the layout engine needs to be re-architected - Jason Smith has said as much in the past. That should have been the focus of 3.0, but of course it’s not sexy and I'm sure that there was pressure from Microsoft to add new features that could be marketed with fanfares. It would not surprise me if Jason and his core team are frustrated by not being allowed to do the re-architecting that they have previously expressed a need for.

Xamarin and Microsoft should be looking over their shoulders at NativeScript and React.Native as real competitors for Xamarin.Forms and not get complacent about performance and stability. They are the key to the future, not new features.

Exactly my thoughts too.
I'll say this again. Xamarin Forms team members are not to blame. I blame the poor, out of focus upper management.

Xamarin Forms could really be a terrific piece of mobile development technology. Xamarin not only needs more people added to the team, but they also need architects and people which have experience in performance and design of the XAML platforms, I'm talking about the great minds at Microsoft. For example people who worked on Windows Phone for example, where the speed is really great. I know it's not the same kind of challenge, but it's similar.

I'm sure that there was pressure from Microsoft to add new features that could be marketed with fanfares

Microsoft and Xamarin shot themselves in their feet with these gimmicks. I'm personally more disappointed with this than of the state of Xamarin Forms. I think Scott Guthrie had an important role in the talks during Xamarin acquisition. The whole thing looks weird to me now. These guys seemed down to earth, I wonder who from all those management layers came with the great idea that the fanfare and gimmicks is the way to go instead of building a bigger and stronger team focused on real stuff. It's crazy just thinking about all the all the platforms, tools, features which Xamarin announced. I personally do not know of any other company which has this much of tools, in all kind of directions, platforms, features.

Same with @Velocity
I also wanted to tell you Xamarin guys that we appreciate you all a lot.
I think that we all have the same mind.
Our wearable app 'allb' would have never been on the market at the right time without Xamarin.Forms.

@DavidAllen said:@DavidOrtinau I think the message you should be taking away from many of the posts here is that there are a lot of very dedicated, and supportive developers using Xamarin.Forms who think the dev team has done an amazing job with the resources they have available and passionately believe in the product, but who are very, very frustrated.

We are frustrated because we don’t see the emphasis on making the product truly industrial strength. There are a lot of words spoken (written), but talk is cheap and we are not seeing the results. You claim there is an emphasis on quality and bug fixes, but our experience is different.

Thanks @DavidAllen, this message is heard loud and clear. As I stated the core team is presently only working on quality issues, and have paused feature work. The great thing about open source is you can look at GitHub, and don't just have to take my word for it.

Please, help persuade the powers that be to postpone new features in favour of improving what is there. The focus of 3.0 is wrong. The performance improvements are a band aid, the layout engine needs to be re-architected - Jason Smith has said as much in the past. That should have been the focus of 3.0, but of course it’s not sexy and I'm sure that there was pressure from Microsoft to add new features that could be marketed with fanfares. It would not surprise me if Jason and his core team are frustrated by not being allowed to do the re-architecting that they have previously expressed a need for.

>

So I think this is again perhaps where a feature roadmap as we have defined and delivered it fails to communicate everything about a product. There is re-architecting and refactoring throughout that is meant to improve performance. The core team is quite excited to have that opportunity with 3.0.

The direction from Microsoft (and Xamarin if we are speaking in those terms) is exactly what I hope everyone is reading from my communications here. We're all on the same page. Quality.

Xamarin and Microsoft should be looking over their shoulders at NativeScript and React.Native as real competitors for Xamarin.Forms and not get complacent about performance and stability. They are the key to the future, not new features.

@DavidOrtinau said:
The direction from Microsoft (and Xamarin if we are speaking in those terms) is exactly what I hope everyone is reading from my communications here. We're all on the same page. Quality.

I have two questions:

Based on what I see in the PRs, the work on performance seemed to me like a shoot and miss game.
Why did the work on "fast renderer" stop? I was expecting to continuously see commits with renderers being changed to "fast renderers".

If you really want to improve things, someone from the team needs to roll up the sleeves and do some tests and benchmarks with actual pages with different controls. You need at least one dedicated person to work on performance and tweak it.
Are you planning a post (or a series of posts) on the blog with details and examples with performance benchmarks and optimizations? I have yet to see something like this.

@DavidOrtinau said:
The direction from Microsoft (and Xamarin if we are speaking in those terms) is exactly what I hope everyone is reading from my communications here. We're all on the same page. Quality.

I have two questions:

Based on what I see in the PRs, the work on performance seemed to me like a shoot and miss game.
Why did the work on "fast renderer" stop? I was expecting to continuously see commits with renderers being changed to "fast renderers".

Fast Renderers involve API changes and fair amount of refactoring. That kind of work introduces the potential for instability. It's a catch-22. The next phase of that work is still planned for 3.0 and Q3.

If you really want to improve things, someone from the team needs to roll up the sleeves and do some tests and benchmarks with actual pages with different controls. You need at least one dedicated person to work on performance and tweak it.

Have you followed the performance thread? If not, I invite you to read that and join the discussion.

Are you planning a post (or a series of posts) on the blog with details and examples with performance benchmarks and optimizations? I have yet to see something like this.

Thanks.

Our performance guide and Evolve 2016 presentation cover a lot of great guidance for optimizing and is still very applicable.

At the risk of stating the obvious, Xamarin Native is also the best of breed performance solution for Xamarin. That's available to you now via custom (page) renderers and in the near future with Forms Embedding.

@DavidOrtinau said:
Fast Renderers involve API changes and fair amount of refactoring. That kind of work introduces the potential for instability. It's a catch-22. The next phase of that work is still planned for 3.0 and Q3.

@DavidOrtinau
I can see that, yes. It's considerable refactoring. Yes, it will bring some regression issues.
But that's not important. What's important is, once you do this rewrite\refactoring, you know you're a much better path.
It's very important to try have a good understanding where you're going with the "fast renderers". Like I mentioned already, you need input from quite experienced people in the architecture and design of frameworks and layout engines.
I hope you will get help your colleagues at Microsoft. To have good performance in the a Xamarin Forms-like framework is serious stuff.

Have you followed the performance thread? If not, I invite you to read that and join the discussion.

I have.

Our performance guide and Evolve 2016 presentation cover a lot of great guidance for optimizing and is still very applicable.

What I meant was, I'd like to see posts which takes a complex page with lots of controls, and show benchmark numbers regarding speed, layout cycles, repaints, etc. You can see these kind of write-ups in front end development for example. I can share an example if you'd like.

At the risk of stating the obvious, Xamarin Native is also the best of breed performance solution for Xamarin. That's available to you now via custom (page) renderers and in the near future with Forms Embedding.

Honestly, since the first time you guys showed this, I could not see much benefit from this feature.
Yes, technically, it's a cool feature, I agree, but how much useful it is?
Do you have some examples of customers which are using these embedding features? I could see some benefit maybe of embedding a native in Xamarin Forms. Maybe.
It might not be very important, but just wondering, have you thought about better communicate the utility of these features? They might look quite confusing. Remember there are still people who can't differentiate well between Xamarin and Xamarin Forms.

Because not all of our technology is open source. Because some customers need to protect their intellectual property and we have signed non-disclosure agreements.

Wouldn't make more sense to share that info privately? Why hide the whole bug? I can't follow any progress, comments, workarounds on that issue. It doesn't make any sense. If there's IP concerns, don't create a bug on Bugzilla in the first place or don't ask a customer to add IP stuff there, such that the bug can remain open... Hiding a bug creates confusion for anyone trying to follow for a solution. Sometimes a bug is marked as a duplicate of a hidden bug!

If everyone could take a peak at the github repository's checkins right now and look at how many bugs are getting squashed! They are running for their dear lives right now. I have a feeling by the end of this, we might have the most stable version yet if this keeps up.

...and say a massive thank you to the Forms team right now. I think this effort will be one for the history books when Xamarin.Forms is viewed down the road.

If everyone could take a peak at the github repository's checkins right now and look at how many bugs are getting squashed! They are running for their dear lives right now. I have a feeling by the end of this, we might have the most stable version yet if this keeps up.

...and say a massive thank you to the Forms team right now. I think this effort will be one for the history books when Xamarin.Forms is viewed down the road.

Yeah, the team seem to be really focused on bug fixes which is great to see.

@BradChase.2654 said:
They are running for their dear lives right now. I have a feeling by the end of this, we might have the most stable version yet if this keeps up.
I think this effort will be one for the history books when Xamarin.Forms is viewed down the road.

Wow, don't you think it's a bit too dramatic and very early to celebrate?
Don't get me wrong, I do appreciate their effort a lot. I love Xamarin Forms.
I've been working with XAML technology stack for many years, for more than 10 years.
Xamarin Forms is not an easy project. The performance and features it takes to make it a truly industrial ready framework and have developers create with it quality apps in a cross platform manner is not a simple job. I have faith Xamarin can do it, especially they're now part of Microsoft, but Microsoft needs to help them. And if I may suggest, Xamarin themselves should try to be more focused.

It's not important what we talk, think or hope, talk is cheap. Time will tell. But the thing is my feeling is every technology has a lifetime, or a moment when it shines and then it dies. I hope XF will reach its full maturity.

By the way, this is just a discussion. So please take it lightly. And there's no intention from me to bash anyone or anything. I love Xamarin, .NET and XAML and I think Xamarin Forms is really an awesome idea (albeit not unique). It's like Windows development stack taking over the tech universe(meaning other platforms).

@fabior I agree that we need a more robust version of the Xamarin Forms XAML previewer.

To preview XAML in a UWP project, I keep a copy of Android built to allow previewer to work.
In my experience, I am not able to be sure that the preview will work each time and there is no sufficient information to tell me why it does not work. I have tried both VS2015 and VS2017.

@DavidOrtinau
Since Xamarin Forms will be coming to WPF. Is it reasonable for US to request for a XAML previewer for Visual Studio 2015/2017 that is independent needing an android project built?

We really need a reliable XAML previewer, when working with either a WPF or an UWP project.

By Q4, with WinOnARM, we can deploy WPF Xarmarin Forms application to cellular PC. The need for a robust XAML previewer will even be greater.

Please log problems you're having to Bugzilla so the tools team can follow up on them.

In terms of sufficient information when preview doesn't work, you should get a message at the top, and if there's stack trace information, clicking the exclamation button should pop up a window with that. It's a pain, but you could also open the Xamarin Logs directory and locate the IDE and/or designer log to find out what is going wrong with the rendering.

@DavidOrtinau yes, I have tried Live Player using VS2017 with Android, Still not satisfying.

The best consistent results I have achieved is through Xamarin Workbook using Android Emulator in Win 10 environment.

I have the feeling that MOST of the testing of XAML Previewer are done in Mac and not Windows 10 to statistically cover all the possible scenarios of Windows 10 users.

I have a few more Great Ideas. Now that AppMap [@BrianLagunas ] is patent pending. I shall reserve further comments :-) I shall Implement these great ideas and open source it through github before being patented by others :-)

Windows 10 hits 500 millions users. By Q3 2017, we can download WSL (Ubuntu, Suse etc) from windows store. By Q4 2017, we will start to reboot "Window Mobile" through WinOnARM with options of UWP (ARM) and Win32 (WPF).

=> The developers for these emerging new ecosystems need Xamarin Forms Designer/Previewer.
=> There is a NEED for a transition from the existing Xamarin Mobile-First (focusing on iOS and Android) to new possibilities presented by OneGUI4all OSs.

Big corporations will appeal to an IT solution that deals with not only mobile but the whole spectrum of users (mobile, laptop, tablet, desktop, linux, max, server etc). - made possible by OneGUI4AALL. Xamarin Forms is IN this position to help IT manager to justify investment into XAMRIN and the promise of more standards to come together with Microsoft.

HOWEVER; All strategy for XAML previewer so far IS ONLY LIMITED to Android and iOS, what about WPF, UWP, GTK+ etc.
=> Why should we bother to install at least JDK1.84 so to use VS2017 XAML form previewer?
=> Why I have to "Pray" each time I want to view a XAML form? It is like someone in the city of ROME looking for a car park, please please, let it works this time.
=> We NEED a Win10 native XAML Previewer/Designer Period.

=> IT IS ABOUT TIME THAT Xamairin WAKE UP and GET READY to this NEW REALITY and THE emerging Non iOS and Android developer DEMANDs, before as some of the users have advocated here, we may just switched to DART, Flutter, Reactive etc.

WHY? Watching Eric Siedel's talk reminds me of this SIMPLE FACT.

With all these BIG PICTURE that will dawn on XAMRIN/Microsoft ecosystem, WHY as a .NET developer, I still have to struggle with some basic day-to-day existence needs [a working XAML previewer] ??? Where is .NET UWP openCV? Where is .NET UWP (non-Unity3D) 3D engine for AR/MR ? Where is .NET UWP deep learning libraries for CNTK and tensorflow etc.

=> Why the brave new vision of OneGUI4ALL does not come as a complete package that make it easy to transition into it - no brainer?

(a) By Q4 2017, much of the 90% best practice in Xamarin Forms using custom controls are still limited to both the iOS and android, XForms for GTK+ and WPF as well as UWP have to keep struggling to learn how the custom controls are done in android and iOS codes [when they are desktop programmers and have no interest to follow tutorial and example codes dominated by Android and iOS for custom control).

(b) WSL is beginning to disrupt the Scientific/data science communities. Many linux die hard are beginning to wake out of the NEW possibilities made possible by staying with ONE host OS (Win10) while working with a range of Linux dialects (not through docker)

In short. I have great hope with XAMARIN. Life as a developer through the XAMRIN technology has changed a great deal for me. I just hate that XAMARIN misses the great opportunities and the RESPONSIBILITIES coming soon.

XAML based presentation layer is the wrong way and I don't think it will have a bright future. Simply look at the github stars of reactnative and compare with xamarin forms. Another alternative alibaba/weex has much more stars, too. The perfect way of doing this is putting a ReactXP like react-native/react.js based technology in the front end, and using c# at the backend of the front-end that are talking each other with a bridge like reactnative inside xamarin runtime. The bridge is similar to client-server json messaging of a web app. This addresses a much wider audience, enables code sharing with web, enables partial code push, faster simpler attractive dev environment like react, simplifies your job (no need for xamarin forms hell).. etc by combining best parts of reactjs/reactnative and xamarin/asp.net core without platform based native coding necessity disadvantage of reactnative. Then you can use the same presentation layer project with an asp.net core project as xamarin and can share presentation layer with web similar to reactxp, and also can use the same c# business logic etc shared code inside both xamarin and asp.net core projects. Javascript/Typescript is the de-facto standard lang for UI and React/Vue are the de-facto standard framework for modern UIs and reactxp/reactjs/reactnative show us that UI sharing with web is possible and has a strong potential. Server side rendering for web is declining, most of it is becoming js/ts based. And then maybe you can perfectly integrate graphql/relay modern with an optional package inside this, too. Trying to make a xamarin forms c# webassembly client for web is also a bad idea. For the desktop, you can use the same stack, native controls with reactxp/reactnative or optionally can use the react.js/web with electron. Some people use a similar custom system using golang for client backend, reactnative for mobile, react.js for both web and desktop (with electron). Golang/react combinations can be threat for xamarin in the near future but have some problems for now and needs some serious resources to solve.

@sirmak well, a lot of people are complaining about the stability of Xamarin (or rather inherent fragility I would say), but that is not even close what I hear from react native. It will take everybody a loooooong time of hard, tedious work to get a cross platform native solution going over iOS / Android / UWP, regardless of the language.

Talking about defacto standard: React and Vue where not here 3 years ago, WPF is 10 years old by now.

@rogihee IMO it's not hard to iron Reactnative to Xamarin and probably some people at xamarin already gave it a look. It can be a new cross platform framework alternative including the web to xamarin forms. For WPF; if you only develop for windows, it's ok. But for cross platform, who cares wpf, it has a tiny mindspace compared to html/js world and js/ts has an extensive usage in server side, too (most of silicon valley knows nodejs for example).

@NMackay XAML/Xamarin Forms WAS a cool tech, but the world is changing rapidly. Today, most of the cross plat. devs want a web based tech with native rendering like reactxp for productivity, faster dev iteration, native controls, code push, and so on.. but their problem is you have to write swift/obj and kotlin/java in native parts, this is where xamarin can rule. Most projects (including enterprise ones) need a web client, so transforming it to include native mobile support is an attractive direction instead of coding as a totally separate project. React native has 50.000+ github stars and 1370+ contributors, xamarin forms has 1400+ stars with 75+ contributors : Do you think there's no problem in that? If the key point is native cross platform, xaml is the wrong direction.

And also flexlayout and css styling in xamForms roadmap are trying to patch the hole a bit, but this seems like a lipstick on a gorilla.

no, Xamarin Forms can be alive for xaml developers but has a tiny slice in the cake. MS and xamarin team has a lot of power and they should put together the right combination with a new cross platform framework alternative to attract most developers, the point is: where the developers/consensus are, MS should be there.

no they can't, this can only be done by xamarin or a totally new product based on golang imo. there is a need for a next gen high performance server side tech like asp.net core or golang, a powerful/modern native compiled lang like c#/go, a perfect mobile tech like xamarin (UI code with typescript and native code with c#) and a team with state of art experience/success in the field like Xamarin Team plus a team of js/ts wizards like visual studio code & typescript & reactxp developers and so on. Also Microsoft has already got supporting services/tools like xamarin test cloud, insights, hockeyapp, azure, IDEs with tooling,..etc

@sirmak You are really suggesting a completely different approach which would be an alternative to Xamarin Forms rather than a possible future roadmap. Personally I would not expect many people to have a great desire to code apps in a combination of C# and javascript.

yes an alternative. most devs already know js. JS/TS for ui is the key for widen platform to web and have a wider audience,
you can see it's success on react native.

Think about developing a crm solution; probably you have to start with web and in the end maybe it will have at least 50.000 lines of js/ts - all is UI logic with lots of css and html components. When you start developing native mobile version with xamarin forms using xaml and c#, you'll have two different UI code bases with two different ui controls/styling, so need more developers and lots of work. You need to develop new features for both in sync with all the complexity. You will already have to write all of this with both js and c#. Think about native tablet and native desktop versions and compare it with web version, shouldn't they to be similar ? Don't you want them in a single code base and use your web front end developers for mobile, too (plus with a faster development cycle) ? If you're experienced in both web and mobile UI, which one can be developed faster/cheaper, XAML one or WEB one ?

ReactXP shows us write once - run everywhere is possible. Yes it doesn't have many controls, tools, framework, etc, but you can think it as a prototype, it has a strong potential; it's not a hybrid solution, it's rendering natively. But as I said, one missing part is mobile native code portion should be written in one language/framework (c#) and this code can be mostly sharable with web server-side.

Not a dream, this is a valid direction in the current tech advancements. Xaml/c# is inappropriate for client side web and for most ui devs, react model is appropriate for both web and mobile ui and has an acceptance by ui devs. IMO, Xamarin team already know what I said well. But unfortunately they may try to support web platform by Webassembly (c#) maybe with the help of Steve Sanderson, and if this happens, it will probably be an ugly thing worse than what the google did with dart. They may choose to make nothing for the web, in all cases I expect we will see more advancements in this direction in the future in go and/or .net camps.

No company make products for charts, they only develop for money (directly or indirectly), but, if you put a good product on the table and if your audience is wide, you can already collect the points and take a big slice from the cake.

The reason why React is so popular without advertisements is, it works really well, it contains lots of advancements, good design decisions, lots of supporting packages and best practices from the UI world and the developer experience is perfect. It was successfully used in production at huge code bases like facebook. Instead, vue / weex can also be used, too for this kind of project.

Github page is enough to see the status of a project; numbers talk, this is the reality. Xam.Forms was a good product, but a team/company like this with weapons like xamarin, .net core, typescript, azure, vs for mac/win, vs code, hockeyapp,.. can make a much much more better cross platform product. You should have accurate/objective predictions about near future, you should see where the world is going. Instead, what we saw in this 8 page roadmap thread over and over again is a drama.

The message is sent, it’s enough. They can consider this or not. I am rolling around like a broken record, and I have no more time.