This roadmap outlines our anticipated feature releases.
Are there things you don't see here that you feel strongly deserve a spot? Make your voice heard and open a proposal on the Xamarin.Forms Evolution forum.
Quality is top of the list. This means stability and performance first and foremost. Xamarin.Forms has been swiftly adopted as a preferred tool for delivering production apps in addition to rapid prototypes. Our focus and priorities are to support the Xamarin.Forms community in those areas. In the release schedule below, we've highlighted how and where we are making those investments.
As this thread is primarily about the feature roadmap, we anticipate the important question "what about ___ bug"?! Improving quality by addressing bugs is huge priority and ongoing focus for the team, in addition to improve our communication across the board.
We cannot predict the future and how everything will shake out. Things will change. Timing may be adjusted due to priority changes, in pursuit of quality standards, or any number of other really good reasons that we will strive to proactively and openly communicate.
We expect to deliver several pre-releases and stable releases during each version series.
Version Series | Estimated Release |
---|---|
2.3 | Q2 2017 |
3.0 | Q3 2017 |
3.1 | Q4 2017 |
Fast Renderers
Label, Image, and Button controls.
Startup Time Improvements
Improve the startup and initialization time for Xamarin.Forms apps.
Xamarin.Forms for macOS Preview
Xamarin.Forms is coming to macOS, joining iOS, Android, Windows, and Tizen as target platforms for Xamarin.Forms.
Bulk renderer creation
Optimize rendering performance on Android with bulk operations.
Cut down on GPU overdraw for Android
Try to avoid overdraw on Android where possible to improve performance.
Layout Compression
LayoutCompression allows multiple layers of Xamarin.Forms layouts to be packed into a single native one.
Fast Renderers for Android
Optimize view renderers to streamline view creation and improve performance. Complete all other UI controls.
Reduce native views created
Cut down on backing native views created for Xamarin.Forms, as noted by Miguel in #42948.
Single DLL
Ship Xamarin.Forms as a single DLL to improve startup performance and assist the linker.
OneTime Binding Mode
A mode to express that a binding only need fire once.
Visual State Manager
Provide a Visual State Manager at the Xamarin.Forms level for managing visual properties of elements across visual states. This will allow developers to control how elements appear when they are disabled, focused, etc.
XAMLC Improvements
Reduce/remove reflection.
Deprecation of WP8.0 and 8.1
This will impact startup time in particular.
.NET Standard 2.0
Xamarin.Forms support.
CarouselView v1 Stable
Stability and performance improvements. See PR.
FlexLayout
Review the original Evolution Proposal. CSS and FlexLayout are now being treated separately.
CSS-Like Styling
Adding the ability to style applications with CSS. Review the original Evolution Proposal. CSS and FlexLayout are now being treated separately.
Xamarin.Forms Embedding
Embed Xamarin.Forms into a native Xamarin.iOS, Xamarin.Android, and UWP.
G18n support
Globalization support enhancements including RTL.
MenuPage
Alternative to the MasterDetail
page, but rendered as a platform-specific menu that makes creating flyouts easy.
Popover Control
A transient view that appears over other content, can anchor to existing UI elements, and resize. Includes nested navigation support.
Xamarin.Forms for macOS
Xamarin.Forms is coming to macOS, joining iOS, Android, Windows, and Tizen as target platforms for Xamarin.Forms.
Xamarin.Forms for GTK#
Xamarin.Forms is coming to Linux.
Xamarin.Forms for WPF
Renderer API Standardization
Make it easier to create custom renderers.
To be determined.
As noted above, the Xamarin.Forms Evolution forum is the place to start.
[Edited 5/18/2017]
Posts
Hopefully you do a good enough job so that I can get rid of all my custom logic in the Prism navigation service and utilize the native implementation
These will be awesome!
Cut down on GPU overdraw for Android - Performance
Try to avoid overdraw on Android where possible to improve performance.
Reduce native views created - Performance
Cut down on backing native views created for Xamarin.Forms, as noted by Miguel in #42948.
Layout Compression - Performance
LayoutCompression allows multiple layers of Xamarin.Forms layouts to be packed into a single native one.
Great to see you guys work on quality. Why wait until May to deliver performance enhancements? I'd address those first instead of spending time on bindable picker, accessibility, macOS, embedding, etc. Regardless, the list looks good.
Thanks @AdrianKnight! I hear you. Performance is hugely important and it's happening. It's easily among the first things I hear when talking to anyone about Forms, and be assured we'll continue beating that drum so it gets all due focus.
I agree with Adrian on waiting till May to deliver performance enhancements.
I would like to see those come sooner than May.
Cut down on GPU overdraw for Android - Performance
Try to avoid overdraw on Android where possible to improve performance.
Reduce native views created - Performance
Cut down on backing native views created for Xamarin.Forms, as noted by Miguel in #42948.
Layout Compression - Performance
LayoutCompression allows multiple layers of Xamarin.Forms layouts to be packed into a single native one.
@DH80 note that Fast Renderers, Startup Improvements, and Compiled Native Views are Performance items and part of the February target. We'll be getting a boost well before May!
@DavidOrtinau yes true very excited about those as well.
Looking forward to Xamarin.Forms for macOS....!
Assuming its native/cocoa (not gtk/x/etc..).
I also look forward to those performance improvements. They sound promising.
Will there be a 2.3.4? Only yesterday somebody asked again what happened to 2.3.4-pre1. It has been removed right after the release and nothing new within 4 weeks. I saw several bugs which say "fixed in 2.3.4-pre1", but that version is not available.
If you skip 2.3.4, then when will we see 2.4.0-pre1? If it should be released in February, then a pre version should be imminent now.
+1 for CarouselView. Finally someone can take a look at my simple pull requests #9 #10. The project is also far too complicated (the .bat file build proccess?) for a person (like myself) to contribute to easily
Thanks a lot for the list, makes sense to me! Very happy to see the performance as top priority!
Please note there is quite a big backlog of small bugfix PR's done by @AdrianKnight for example. Ideally, I think the number of open PR's should be as low as possible. How does reviewing and validating PR's fit in the Roadmap?
After review and approval, will the PR get a badge for the intended release when at latest it will be merged? Then there is a deadline per PR and for the submitter it is clear when a merge is expected.
@MichaelRumpler You can just go download the code for it https://github.com/xamarin/Xamarin.Forms/releases/tag/beta-2.3.4-pre1. You will notice there were way too many issues with it. I wouldnt be surprised if they just skip the entire release. That said I too +1 on the earlier the better on performance. This is one of the biggest concerns for us besides the Label renderer and the massive performance hit we get from the fact DataTemplates are rendered before ever even being used. https://bugzilla.xamarin.com/show_bug.cgi?id=45179. We use ALOT of templates.
Good luck X.Forms, I am glad you guys are addressing the issues and the community! This is a big step in getting back on track.
@MichaelRumpler @BradChase.2654 I'm looking into this today. My understanding right now is we have addressed all blockers to pushing 2.3.4 out as a pre and getting everyone banging on it again.
Keep in mind, this roadmap is specifically feature releases in the broader scope and doesn't encompass every detail of the Forms release world. As I codify other processes and release plans, I'll get those out here in another thread and likely on GitHub so we have visibility and discussion and set clearer expectations.
Anything else you want clarity and visibility on, let me know. What I'm hearing now is:
Thanks for patience especially initially as I get my bearings. I'll get info out as quickly as I can. I don't want to jump the gun and spill bad info.
@DavidOrtinau My understanding from what we noticed is you still cannot add Event handlers into XAML with the latest version of forms with XAMLC turned on. There were alot of issues with the latest XAML reader...
EDIT: That reminds me to ask if these changes to the forms team are going to include some sort of an internal testing phase with a team dedicated to testing? Along with that will there be a serious attempt at trying to figure out issues rather than just," I tried it in 5 minutes and could not reproduce, please enter an entire project in bugzilla and we might look at it" answer we typically get? I think that would show that you are dedicated to the community and the Forms project...
David,
First of all, congrats to your new role in the Xamarin Forms team!
It's a nice roadmap but shouldn't the roadmap items include links to GitHub like branches or PRs? That's how many other OSS projects do it.
Including the links to Github would:
You could still have a thread here for discussing but a better place for the roadmap I think is on GitHub Wiki, for example see TypeScript's https://github.com/Microsoft/TypeScript/wiki/Roadmap
I'm particularly interested about these two items in the roadmap for February :
Fast Renderers - Performance
Optimize built-in and custom view renderers to streamline view creation and improve performance.
Startup Time Improvements - Performance
Improve the startup and initialization time for Xamarin.Forms apps.
Is there any branch or PR currently for these two or are we expected to see them suddenly pop out in February (which is just few weeks away by the way)?
Nice to see, that Xamarin starts to have a roadmap
Please do this also in the future and hold your promise:
Thanks!
@AndrewMobile thanks! I'm in favor of leveraging GitHub for wiki and roadmap etc.
In drafting our roadmap, I referenced several others. Anything like that that you think would make the Roadmap more useful, I'll definitely entertain it. It's not a marketing piece, it's to increase visibility with the community about what's being done and planned. Not everything will make sense to include on the feature roadmap, but if it's something we need out there, I'll find the right place for it.
re: branches - commits and PRs in GitHub is where the most recent stuff lives and we are moving towards that everywhere possible. Which means, there's some stuff that predates or is spiked on the side and not reflected yet in the main repos. I'm getting a grasp on that and I think it's fair to ask "where's the work" and "when can we expect to see progress".
Thanks @FredyWenger! As I've mentioned elsewhere to @AdrianKnight, please do keep me accountable. It's not an easy proposition what's being done here, but everyone's heavily invested.
For sure, we can all expect XAML Previewer to only get better as it approaches release. You may already realize this, but although it's in the Stable channel, it is still a Preview release. We should try to get some kind of badge on it to make that clear.
@DavidOrtinau - This might be a question for the Test Cloud team, but is there any update on when Xamarin.UITest will support all Xamarin.Forms supported platforms? I'm holding off on any further UITest work until I can use one set of tests across Android, iOS and UWP. Obviously, support for WinRT would also be useful too, but UWP is more important for me.
Yeh, that's really a TestCloud discussion. I'll see what details I can get regardless.
YES!
XF Feature Roadmap... all time favorite thread on X forum!!!
...and yes noticed the Xamarinian "X" on your pic.. congrats @DavidOrtinau on your new role with the Xamarin Forms team!
For February 2017, you list:
Do you mean Windows Phone 8 or Windows Phone 8.1/Windows 8.1?
Cheer up!
Thanks Xamarin.Forms team.
I believe XF is the frickin future of mobile development. (+ even desktop)
And what you guys have done so far is great job.
Windows Phone 8
First of all, congrats @DavidOrtinau !!
Second, I can't begin to express my gratitude on seeing a "Roadmap".
It is really a change for us, old Xamarin users.
And if possible, I too would vote for roadmaps on GitHub like TypeScript, for sure it makes it more visible for anyone looking at the project from "that side".
Can I expect the previewer will work in Visual Studio for android without a Mac connection? I was so surprised when learned an Mac is needed currently.
[EDIT] Pierce just told me I might be wrong about this. What?! Grabs pitch fork. I'm being told there's a fix and it's coming. Let me find out more and I'll report in another thread since Previewer isn't really on topic. [/EDIT]
I think you're fine. Mac is required when doing iOS development. If you're doing Android on Windows and using Visual Studio you are fine. Here are some good resources about the XAML Previewer:
https://developer.xamarin.com/guides/xamarin-forms/xaml/xaml-previewer/
https://blog.xamarin.com/live-xaml-previewing-with-the-xamarin-forms-previewer/
@DavidOrtinau I hope the MenuPage feature could make to 2.4.0 release. Is that possible? I think this feature is quite important if you are planning a new app right now.
@VincentWang: You can use a
MasterDetailPage
as a workaround in the meantime. TheMenuPage
just cuts down on the excessive amount of boilerplate code you need to have a flyout control. You can copy/paste my code from my Yammer clone, which products a pretty niceMenuPage
:https://github.com/pierceboggan/learn-azure/tree/master/apps/unconnected-app
I tried lots of times every time when there is a new blog that mentioned it. It never worked and I am not alone. Others ran into this same problem as well.
Yes, see my revised comment above. Sorry. I'm as surprised as you.
We just posted a proposal draft for the Accessibility (A11y) Support feature in the Evolution forum. I've added the link above, but you can also get there here: https://blog.xamarin.com/live-xaml-previewing-with-the-xamarin-forms-previewer/
What about official .NET Standard support (with an updated VS template)? I know it works as-is with some extra steps, so this should be pretty easy.
It's on our radar for sure. You'll see it appear on the roadmap in due course.
@PierceBoggan @DavidOrtinau -
A while ago, I outsourced (at my own expense!) development of drag & drop functionality for use in my first app. There's still work to be done (the biggest bit is that UWP is not working currently), but the code so far can be found at https://github.com/johnshardman/XF_DragAndDrop
If nothing else, it shows that it can be done (subject to getting it working on UWP). Any chance of the Xamarin.Forms team taking this over, completing & enhancing, to get it built into ListView at some point in future, even if a fairly distant future?
This is probably not the correct place, but I couldn't find any other info about the MenuPage in the evolution forum or the github pull requests.
The MasterDetailPage can use the Master as a flyout so that it overlaps the Detail or they can be shown side by side when you use MasterBehavior=Split. Then the Detail width is not the full page width.
What I am missing is that the user can swipe in/out the Master and the Details width is adjusted to be the rest of the page. The two pages should not overlap, but the user can still decide whether he wants to show the Master (Detail has less space) or not (Detail has full width).
Maybe you can design the MenuPage so that it supports this (or enhance the MasterDetailPage).
Where would be the proper place for this? In the evolution forum? In UserVoice? In the forms-devel mailing list? In Bugzilla? I still don't get the difference. You have too many tools!
Thx @JohnHardman. That's certainly worth more conversation. I'll ping you directly.
Yes, we want to have those kinds of conversations in the Evolution forum. We need to get our thoughts out there as we did yesterday with Accessibility so it's not just a mention on the Roadmap. And we didn't want to further delay the Roadmap. So, give me a bit to make that happen.