locked
Xamarin.Forms Feature Roadmap RRS feed

  • Question

  • User130 posted

    The latest Xamarin.Forms Feature Roadmap is posted to the project's GitHub Wiki.

    Please use this forum thread to discuss how you'd like to see Xamarin.Forms grow.

    [Edited 1/5/2018]

    Tuesday, January 3, 2017 10:16 PM

All replies

  • User116727 posted

    Prism-Like URI Navigation Routing - Enhancement Navigate to a page using Uri navigation, similar to what Prism does.

    NavigationService.NavigateAsync("ListPage/DetailPage?id=1");

    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 :)

    Tuesday, January 3, 2017 10:50 PM
  • User4685 posted

    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.

    Tuesday, January 3, 2017 11:05 PM
  • User181025 posted

    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.

    Wednesday, January 4, 2017 12:16 AM
  • User130 posted

    @AdrianKnight said: 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.

    Wednesday, January 4, 2017 1:13 AM
  • User26553 posted

    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.

    Wednesday, January 4, 2017 3:30 AM
  • User130 posted

    @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!

    Wednesday, January 4, 2017 3:42 AM
  • User26553 posted

    @DavidOrtinau yes true very excited about those as well.

    Wednesday, January 4, 2017 3:44 AM
  • User732 posted

    Looking forward to Xamarin.Forms for macOS....! Assuming its native/cocoa (not gtk/x/etc..).

    Wednesday, January 4, 2017 3:54 AM
  • User57869 posted

    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.

    Wednesday, January 4, 2017 7:05 AM
  • User67129 posted

    +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

    Wednesday, January 4, 2017 8:44 AM
  • User311 posted

    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.

    Wednesday, January 4, 2017 10:18 AM
  • User139040 posted

    @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.

    Wednesday, January 4, 2017 3:07 PM
  • User130 posted

    @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:

    • contribution and PR processes, status
    • minor releases

    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.

    Wednesday, January 4, 2017 3:26 PM
  • User139040 posted

    @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...

    Wednesday, January 4, 2017 4:41 PM
  • User19820 posted

    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: - reassure people that roadmap is real and being followed - provide more insight and understanding what the roadmap item is (the simple description doesn't always make sense) - give people an easy way to track progress on each roadmap item - make it easier for contributors to step in and help

    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)?

    Wednesday, January 4, 2017 5:49 PM
  • User65389 posted

    Nice to see, that Xamarin starts to have a roadmap :smile: Please do this also in the future and hold your promise:

    Quality is top of the list. This means stability and performance first and foremost

    Thanks!

    Wednesday, January 4, 2017 5:59 PM
  • User130 posted

    @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".

    Wednesday, January 4, 2017 7:06 PM
  • User130 posted

    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.

    Wednesday, January 4, 2017 7:29 PM
  • User250767 posted

    Also solve Issue with vs and make xaml previewer more strong ....most problem I face is designing the page...

    Wednesday, January 4, 2017 8:22 PM
  • User130 posted

    @bprasad said: Also solve Issue with vs and make xaml previewer more strong ....most problem I face is designing the page...

    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.

    Wednesday, January 4, 2017 9:20 PM
  • User89714 posted

    @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.

    Thursday, January 5, 2017 12:03 AM
  • User130 posted

    @JohnHardman said: @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.

    Thursday, January 5, 2017 1:01 AM
  • User27668 posted

    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!

    Thursday, January 5, 2017 4:34 AM
  • User74406 posted

    For February 2017, you list:

    • Deprecation of WP8

    Do you mean Windows Phone 8 or Windows Phone 8.1/Windows 8.1?

    Thursday, January 5, 2017 4:34 AM
  • User221964 posted

    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.

    Thursday, January 5, 2017 9:20 AM
  • User130 posted

    @Andrew.3192 said: For February 2017, you list:

    • Deprecation of WP8

    Do you mean Windows Phone 8 or Windows Phone 8.1/Windows 8.1?

    Windows Phone 8

    Thursday, January 5, 2017 3:03 PM
  • User162440 posted

    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".

    Thursday, January 5, 2017 8:41 PM
  • User118255 posted

    @DavidOrtinau said:

    @bprasad said: Also solve Issue with vs and make xaml previewer more strong ....most problem I face is designing the page...

    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.

    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.

    Thursday, January 5, 2017 9:04 PM
  • User130 posted

    @Vincentwx said:

    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/

    Thursday, January 5, 2017 9:11 PM
  • User118255 posted

    @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.

    Thursday, January 5, 2017 9:11 PM
  • User43 posted

    @VincentWang: You can use a MasterDetailPage as a workaround in the meantime. The MenuPage 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 nice MenuPage: https://github.com/pierceboggan/learn-azure/tree/master/apps/unconnected-app

    Thursday, January 5, 2017 9:16 PM
  • User118255 posted

    @DavidOrtinau said:

    @Vincentwx said:

    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.

    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/

    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.

    Thursday, January 5, 2017 9:21 PM
  • User130 posted

    @Vincentwx said:

    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.

    Thursday, January 5, 2017 9:25 PM
  • User130 posted

    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/

    Thursday, January 5, 2017 9:32 PM
  • User112992 posted

    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.

    Thursday, January 5, 2017 9:35 PM
  • User130 posted

    @JeremyHerbison said: 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.

    Thursday, January 5, 2017 9:54 PM
  • User89714 posted

    @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?

    Thursday, January 5, 2017 11:47 PM
  • User57869 posted

    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!

    Friday, January 6, 2017 8:38 AM
  • User130 posted

    @JohnHardman said: @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?

    Thx @JohnHardman. That's certainly worth more conversation. I'll ping you directly.

    Friday, January 6, 2017 2:15 PM
  • User130 posted

    @MichaelRumpler said: 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!

    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.

    Friday, January 6, 2017 2:20 PM
  • User171749 posted

    @JohnHardman said: @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?

    I don't mind building a DraggableGestureRecogniser similar to what I did with the SwipeGestureRecogniser?

    https://github.com/xamarin/Xamarin.Forms/pull/657

    Friday, January 6, 2017 2:45 PM
  • User89714 posted

    @DavidOrtinau - Accessibility is a NFR that many developers overlook. A big thumbs up from me for getting it visibly on the roadmap. The statistics for how many potential users are excluded by not supporting accessibility come as a surprise to most devs. Supporting accessibility is not just the right thing to do, it also increases potential revenues by increasing the number of potential users of an app.

    (It's also one to bear in mind when looking at drag & drop, which is inherently accessibility-unfriendly. Any functionality that is implemented using drag & drop also has to have a more accessibility-friendly method of use).

    Data protection legislation is another area that often gets overlooked. Whilst I understand you are looking primarily at XF, is anybody publishing a roadmap for Insights/HockeyApp? It's vital that it takes into account data protection legislation in different parts of the world. In the work I am doing with Xamarin.Forms, I am using Insights & HockeyApp during development, but I will be replacing it before going to production unless legislation is taken into account. I hope that the Microsoft acquisition of Xamarin will result in Microsoft's understanding of global issues resulting in products being updated, but a timescale would be useful.

    Friday, January 6, 2017 2:46 PM
  • User160216 posted

    :) Feeling relieved. Lots of questions answered.

    Friday, January 6, 2017 7:01 PM
  • User4513 posted

    @DavidOrtinau - thanks David. At last, it feels like the XF product team are listening to what the community really wants, rather than getting excited about lots of cool new features (understandable as developers always want to do something new, but not what we need!). XF is now feature rich enough to be a serious candidate for mainstream development, however stability and performance (especially on Android) are serious concerns. Thank you to the entire XF team for recognizing that and seriously planning to address those.

    Friday, January 6, 2017 11:07 PM
  • User111298 posted

    Great to see the new roadmap. Congrats to David.

    2.5.0 - May 2017 Xamarin.Forms Embedding - Feature Embed Xamarin.Forms into a native Xamarin.iOS, Xamarin.Android, or Windows 10 app.

    Does this mean native XAML and XF XAML can live together in the same view or are we saying a separate view for native and XF ?

    This would be a really great feature especially enhancing XF with more native UWP desktop PC form factors. Can't wait !! Any plans to work closer to the template10 guys on UWP ? They doing a great job and it would be awesome to see closer integration between Xamarin and Template10.

    Saturday, January 7, 2017 11:10 AM
  • User230357 posted

    Really good stuff here. Congrats on the continuing progress.

    I was looking at OS share stats yesterday and made some projections. Based on Statscounter data.

    Worldwide Xamarin.Forms covers basically 100% of smartphones and 39% of desktops, 46% projected in 1yr. With Mac OS this goes up to 100% of smartphones and 50% of desktops now, 58% in 1yr.

    Now... if Xamarin.Forms could target WPF too it would cover 100% of smartphones and 93% of desktops now, 97% in 1yr.

    That would be highly impressive and very attractive I think for developers.

    Something to consider after MacOS support?

    Saturday, January 7, 2017 4:18 PM
  • User111298 posted

    I agree @CharlesRoddie with cross platform footprint , but i would change WPF for HTML5 derived from XAML (website). Dreaming here ;)

    Similar to the project cshtml5.com that would surely push that desktop figure to 100% in one go.

    Imagine writing XAML on all platforms including web and c# code transpiled into typescript (that is also useful in angular)

    Sunday, January 8, 2017 2:48 PM
  • User230357 posted

    Interesting idea and I'm sure I'd use it if it were available. But it would be the other end of the spectrum from WPF support in terms of implementation difficulty, and also performance!

    Sunday, January 8, 2017 3:33 PM
  • User90905 posted

    @JohnHardman said: Data protection legislation is another area that often gets overlooked. Whilst I understand you are looking primarily at XF, is anybody publishing a roadmap for Insights/HockeyApp? It's vital that it takes into account data protection legislation in different parts of the world. I just wanted to say that I also feel like this is pretty important. I personally have zero knowledge of all the different laws.

    Sunday, January 8, 2017 4:31 PM
  • User89714 posted

    @JensDemey - The legislation varies a lot between countries. A very quick summary...

    In the UK, we have the Information Commissioner's Office, which publishes all sorts of material relating to this. The EU has a set of rules that the UK is currently signed up to (realistically, that will probably still be true even if Brexit does happen). The EU rules are changing soon, but again information is available online. The ICO has a brief overview at https://ico.org.uk/media/for-organisations/documents/1624219/preparing-for-the-gdpr-12-steps.pdf

    The EU used to allow data to be transmitted to US companies under what was called Safe Harbor. A recent court ruling has ruled that Safe Harbor does not offer the necessary level of protection. This is why Xamarin.Insights only using servers in the USA is problematic if the data transferred might be personally identifiable. I would hope that the migration to HockeyApp would resolve this, but I do not know.

    Some (non-EU) countries require that data be stored not just within the same region, but within the same country.

    There are even countries that impose a firewall around themselves, which can prevent reliable or performant communication with servers elsewhere. The Great Firewall of China is the best known example of this. Trying to test mapping software across that firewall caused me some headaches. I certainly wouldn't try using blockchain across it any time soon.

    And then there are specific company requirements. Some corporate customers may require that analytics are stored on the company's own infrastructure rather than being sent to Xamarin/Microsoft servers. That's not legislation, but the rules of individual companies.

    Sunday, January 8, 2017 5:36 PM
  • User130 posted

    @lpdavies said:

    @JohnHardman said: @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?

    I don't mind building a DraggableGestureRecogniser similar to what I did with the SwipeGestureRecogniser?

    https://github.com/xamarin/Xamarin.Forms/pull/657

    How about we get those open in the Evolution forum for further exploration / discussion?

    Monday, January 9, 2017 3:57 PM
  • User171749 posted

    @DavidOrtinau said:

    @lpdavies said:

    @JohnHardman said: @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?

    I don't mind building a DraggableGestureRecogniser similar to what I did with the SwipeGestureRecogniser?

    https://github.com/xamarin/Xamarin.Forms/pull/657

    How about we get those open in the Evolution forum for further exploration / discussion?

    I would but I'm not sure how I would design the API yet and I don't have a good enough use case to make a thread :( Ill have a think tonight.

    Monday, January 9, 2017 4:56 PM
  • User172849 posted

    Deprecation of WP8

    I know that this is an old platform, but this is a dealbreaker for us.

    We have a major customer with thousands of devices in many countries around the world, and replacing them all is prohibitivly expensive. If this happens, we will not be able to upgrade to any future version. Please reconsider.

    Monday, January 9, 2017 10:39 PM
  • User130 posted

    @MercifulGiraffe said: Deprecation of WP8

    I know that this is an old platform, but this is a dealbreaker for us.

    We have a major customer with thousands of devices in many countries around the world, and replacing them all is prohibitivly expensive. If this happens, we will not be able to upgrade to any future version. Please reconsider.

    Let's talk about this and what your options might be. I'll reach out directly.

    Monday, January 9, 2017 10:41 PM
  • User251799 posted

    Any word on push notification support? It appears Google Could Messaging (GCM) is deprecated (I can't even register a GCM API key anymore in Azure, since Google stopped accepting new keys that aren't Firebase), and Xamarin Forms is still maintaining a hard dependency on Google Play Service 29.0.0.1. As far as I can tell, push notifications with XF/Android are broken for new projects - this has showstopper quality for the whole platform IMO.

    Saturday, January 14, 2017 11:07 AM
  • User130 posted

    @PhilippSumi said: Any word on push notification support? It appears Google Could Messaging (GCM) is deprecated (I can't even register a GCM API key anymore in Azure, since Google stopped accepting new keys that aren't Firebase), and Xamarin Forms is still maintaining a hard dependency on Google Play Service 29.0.0.1. As far as I can tell, push notifications with XF/Android are broken for new projects - this has showstopper quality for the whole platform IMO.

    As mentioned in the 2.3.4.184-pre1 thread, the dependency is still present and thus nothing is changed on that front yet. It's a well known pain point and we hope to have a way forward soon. I'll eagerly share progress on this as I have it.

    If Azure is an option for you, push notifications are working there last I checked.

    Saturday, January 14, 2017 3:30 PM
  • User251799 posted

    @DavidOrtinau said: If Azure is an option for you, push notifications are working there last I checked.

    I am running an Azure Notification Hub, but Azure relies on GCM. I tried registering my GCM key with my Azure Notification Hub but got an error from the Google side - apparently, they stopped supporting new registrations in September, but require FCM server IDs. Registering my FCM server key works of course, but that gets me to the FCM problem on Android.

    Please correct me if I'm wrong (I'd really love to be wrong ;)

    Saturday, January 14, 2017 3:49 PM
  • User278242 posted

    Xamarin.Forms Embedding - Feature Embed Xamarin.Forms into a native Xamarin.iOS, Xamarin.Android, or Windows 10 app.

    This unlocks many features such as having Android Fragments with forms!

    Monday, January 16, 2017 12:09 AM
  • User221964 posted

    @PhilippSumi Hi, Push notification is working fine for me on XF/Android. I registered on Firebase and got a key (FCM). And I use it with GCM framework on XF/Android. I'm not using Azure server.

    Is this what you're talking about? Maybe not?..

    Monday, January 16, 2017 6:03 AM
  • User251799 posted

    @BBright said: @PhilippSumi Hi, Push notification is working fine for me on XF/Android. I registered on Firebase and got a key (FCM). And I use it with GCM framework on XF/Android. I'm not using Azure server.

    Is this what you're talking about? Maybe not?..

    Yay! I got it to work with a completely new GCM setup:

    • Created a new project in the Google API console
    • Enabled GCM and created an API key for it. Restricted the API key to my Android app.
    • Created a new Firebase project by importing the Google project
    • Registered the Firebase Server key (the new long one) in Azure Notification Hub
    Monday, January 16, 2017 9:11 AM
  • User62776 posted

    Thanks for the roadmap, great to see how far things have come!

    Quality is top of the list. This means stability and performance first and foremost.

    This is definitely one of the biggest pain points when writing professional apps for paying customers. The coming features look great but hope the standard of quality and performance will improve!

    It would also be great to finally get a bindable span!

    Monday, January 16, 2017 10:30 AM
  • User291766 posted

    @DavidOrtinau Can you elaborate further on the feature details of Xamarin Forms Embedding in native Xamarin.iOS and Xamarin.droid apps slated for v2.5?

    Monday, January 16, 2017 11:44 AM
  • User130 posted

    @MichaelZ said: @DavidOrtinau Can you elaborate further on the feature details of Xamarin Forms Embedding in native Xamarin.iOS and Xamarin.droid apps slated for v2.5?

    We'll get a proposal added to the Evolution forum with more details.

    Basically you'll be able to take things like a ContentPage and use it as a control in Xamarin.iOS and Xamarin.Android.

    Monday, January 16, 2017 8:38 PM
  • User250320 posted

    Missing Desktop things like cursors, mouse overs, drag and drop, skinable buttons (i.e. gray buttons on UWP don't fly in 2017 and need to have the same functionality as UWP XAML)

    Tuesday, January 17, 2017 4:13 PM
  • User216219 posted

    My relationship with Xamarin development has been a kind of love / hate event from the start. I love developing in C# cross-platform. I love how .NET core came along and allowed me to develop the back-end API as fast as my fingers and thoughts will allow and have it sitting on a cheap Linux box with Postgresql to store and serve my data.

    But the front-end? SIGH. I hate how clunky it feels by comparison. I hit compile about 2 minutes ago and it's still going. So here's a thought - when we're looking at optimization, as developers we seek out the big gains, the steps we deduce are taking too much time, and we address those first. So why not devote 1-2 iteration cycles to this, but looking at the entire development process.

    My votes would be:

    Android linking - specifically zipalign.exe and building the APK . Let's get the android compile time to the same level as the PCL compile time. And why compile the APK again if I haven't made any changes? Visual Studio should intelligently just check and relaunch what I had before.

    Mono / forms startup & screen display time. I began developing my app in Xamarin Forms. That gave me a 6 second cold startup time and a noticeable lag in screen to screen navigation on my Note 3. Abandoned that for Xamarin Native which shows my splash screen after 1 second but still takes 4 seconds total (sometimes 5) to cold start. My app doesn't do any complicated processing. Surely this can be bettered? I don't currently anticipate getting close to any of the best times logged here: http://blog.nimbledroid.com/2016/02/17/cold-start-times-of-top-apps.html?top?=25&category=MUSIC_STREAMING People really started paying attention when kestrel started to fly (https://vimeo.com/172009499)

    UI design. The android screen designer currently doesn't render everything and also slows down to the point of crashing if you use it too many times. I think these are in the process of being fixed, but what about drag and drop screen creation?

    Design templates. OK, I admit - I'm graphically challenged. Make it easy for professional graphic designers to produce high quality designs (IN AXML!) that can be quickly integrated to make good looking apps.

    On a separate note, my ultimate development fantasy (I do need to get out more) is to create a XF implementation from the group-up which uses a managed C# HTML 5 renderer that is implemented across all platforms and supports C# view models behind the HTML UI. Forget about slavishly following all of the vendor UI changes in XF, just tweak the CSS and it looks like Android, iOS or WP - compiled or interpreted, you choose. Team that with fully supported cross-platform implementations for purchasing, push messaging, secure storage, device info etc and you're looking at the most capable mobile development platform on the planet :-)

    Finally, release Xamarin Profiler for everyone with a professional VS subscription. Pretty please?

    Wednesday, January 18, 2017 8:14 PM
  • User216219 posted

    While I'm on a roll. Just compiled my app for release and it won't talk to my server, whilst the debug version works perfectly. No idea why, but I'm sure I'll find out in about 4-8 hours :-( That's my average TTS (time to solution) when something doesn't work in Xamarin. It's all about the cycle.

    Wednesday, January 18, 2017 8:25 PM
  • User130 posted

    @PaulVipond said: While I'm on a roll. Just compiled my app for release and it won't talk to my server, whilst the debug version works perfectly. No idea why, but I'm sure I'll find out in about 4-8 hours :-( That's my average TTS (time to solution) when something doesn't work in Xamarin. It's all about the cycle.

    Hey Paul, thanks for all your feedback. We are doing work on performance, both in the near term as shown on the roadmap, as well as long term.

    2 minute compiles and issues talking to your server in release are NOT to be expected and you've every right to put that in the "hate" column. Let's get that looked at. I'll message you directly and let's find the right channel for you to get some answers.

    Thursday, January 19, 2017 3:31 AM
  • User113114 posted

    @PaulVipond said: While I'm on a roll. Just compiled my app for release and it won't talk to my server, whilst the debug version works perfectly. No idea why, but I'm sure I'll find out in about 4-8 hours :-( That's my average TTS (time to solution) when something doesn't work in Xamarin. It's all about the cycle.

    Do you use modernhttpclient? if so, test to delete it

    Thursday, January 19, 2017 2:34 PM
  • User292806 posted

    @DavidOrtinau said:

    @PhilippSumi said: Any word on push notification support? It appears Google Could Messaging (GCM) is deprecated (I can't even register a GCM API key anymore in Azure, since Google stopped accepting new keys that aren't Firebase), and Xamarin Forms is still maintaining a hard dependency on Google Play Service 29.0.0.1. As far as I can tell, push notifications with XF/Android are broken for new projects - this has showstopper quality for the whole platform IMO.

    As mentioned in the 2.3.4.184-pre1 thread, the dependency is still present and thus nothing is changed on that front yet. It's a well known pain point and we hope to have a way forward soon. I'll eagerly share progress on this as I have it.

    If Azure is an option for you, push notifications are working there last I checked.

    David, could you tell us please, just approximate dates when planned to implement FCM support for Xamarin Forms (dependence on Android.Support v. 24.2+). One week, one month, one year? I just have a big problem now.

    Our company developing an application for a customer within the last 6 months using Xamarin Forms. Now the development has reached the Push-notifications integration (without Azure) and I cannot integrate the FCM in our project. Moreover, for the other customer we now launching a new project, also on Xamarin Forms. A few months later the same problem will arise in new project too.

    So, I don’t know what I should to do now. What I must say to my current customer, and how to plan my new project? I'd be very grateful for any advice.

    Thanks, in advance.

    Thursday, January 19, 2017 3:29 PM
  • User216219 posted

    @Firefly before I moved to Xamarin Android my push messaging was working fine with a FCM key and this cross-platform plugin: https://github.com/rdelrosario/xamarin-plugins/tree/master/PushNotification I did, however, download the source and recompile it against the latest support libraries to get it working. Tested and working well on Android.

    Friday, January 20, 2017 12:47 AM
  • User221964 posted

    @Firefly Why don't you try FCM with GCM library, like @PaulVipond said, try rdelrosario's push plugin with FCM key. That's what I did and it's been working fine.

    Friday, January 20, 2017 3:13 AM
  • User81057 posted

    Great to see the focus on performance, android especially could use some improvements. Its a shame you don't offer the easy ability to just AOT selected assemblies instead of the entire app, from my experiments hacking at the msbuild files you really only need to AOT the main app assembly and a couple of xamarin assemblies to get improved startup and performance on android. AOT adds bloat to the already large apk, so some sort of UI to select which assemblies should be AOT'd would be nice.

    Talking of bloat, xamarin currently stores the assemblies uncompressed in the APK, where as with the enterprise version of xamarin you bundle them into a native lib (which gets compressed). Why not compress the assemblies in the non enterprise version - i'm not bothered about the additional 'security' of bundling, but would like the smaller APK size.

    Friday, January 20, 2017 6:32 AM
  • User258 posted

    @PaulVipond said: On a separate note, my ultimate development fantasy (I do need to get out more) is to create a XF implementation from the group-up which uses a managed C# HTML 5 renderer that is implemented across all platforms and supports C# view models behind the HTML UI. Forget about slavishly following all of the vendor UI changes in XF, just tweak the CSS and it looks like Android, iOS or WP - compiled or interpreted, you choose.

    I like the base concept, but would prefer something like flutter from google. I believe the presentation layer is based on Skia : https://flutter.io/faq/

    Watching a flutter presentation a while back, I remember them saying that most of the the award winning apps don't follow vendor UI anyway. So what was true a few year back (stick to the platform UI paradigms) does not necessarily apply anymore. XF might as well supply a new category of UI widgets. Come on XF team. Dip your toes in those waters :)

    Too bad NGraphics/NControls did not take it to this level: https://github.com/chrfalch/NControl

    Friday, January 20, 2017 7:30 AM
  • User171749 posted

    @DavidOrtinau Do you have an ETA for the CarouselView release? Do you think it will be early or late February? I'm doing a project and I'm not sure whether I should add the CarouselView or not since it needs to be live in a couple of weeks.

    Friday, January 20, 2017 8:23 AM
  • User292806 posted

    @PaulVipond @BBright Thanks for your answer, but is this a reliable solution to use FCM with GCM library? FCM doesn’t have to support GCM protocols, am I right? Nevertheless, we will have this solution as a plan “B”. Still waiting for @DavidOrtinau ’s answer.

    Friday, January 20, 2017 9:03 AM
  • User216219 posted

    @Firefly there's a thread here that discusses GCM versus FCM. http://stackoverflow.com/questions/37311188/migration-from-gcm-to-fcm-needed You'll have to judge reliability for yourself, but the general consensus is that FCM is a superset of GCM.

    @void Thanks for links. I haven't seen Flutter or the NGraphics/NControls project. The NGraphics one would have been perfect for one part of my app, had I continued with XF.

    Friday, January 20, 2017 12:12 PM
  • User66766 posted

    @DavidDunscombe partial AOT is what I would call it. Jon Pryor and I were discussing this same thing as well and he came up with this:

    https://github.com/jonpryor/Scratch.MyCamera/blob/jonp-partial-aot/Documentation/PartialAOT.md

    I can confirm that is does improve startup time for Android and adds about 20 MB to the total app size on the device. A lot less than full AOT.

    Friday, January 20, 2017 3:10 PM
  • User81057 posted

    @void said:

    Watching a flutter presentation a while back, I remember them saying that most of the the award winning apps don't follow vendor UI anyway. So what was true a few year back (stick to the platform UI paradigms) does not necessarily apply anymore. XF might as well supply a new category of UI widgets. Come on XF team. Dip your toes in those waters :)

    Too bad NGraphics/NControls did not take it to this level: https://github.com/chrfalch/NControl

    I've played around with using SkiaSharp for rendering controls in a couple of ways, its certainly a quick library.

    I while back i had a go at porting Xamarin Forms to the Raspberry PI using SkiaSharp (https://github.com/roceh/Xamarin.Forms/tree/skia) it actually ran quite well using a non accelerated pure frame buffer (with what few controls i ported) so I've no doubt GPU accelerated SkiaSharp Xamarin Forms running on Android/iOS would be quite snappy.

    I also did a partial SkiaSharp xaml layout container which I've used primary for complex viewcells for performance reasons on Android (https://github.com/roceh/MycoLayout), I was surprised it was faster (as it creates and destroys bitmaps at a fair rate), but the multitude of views on complex layouts that Xamarin Forms Android creates and the interop costs surrounding all that really hurts performance. One of the reasons the May update looks really hopeful.

    Friday, January 20, 2017 7:32 PM
  • User216219 posted

    @BjornB Interesting tip on ModernHttpClient thanks. I'm using MvvmCross and had this defined as part of my IoC setup:

            Mvx.RegisterType<HttpClient>(() =>
            {
                return new HttpClient(new NativeMessageHandler());
            });
    

    So removed new NativeMessageHandler() from the constructor and yay - it starts working in release mode. I commented it back in to check that was definitely the issue and ... you guessed it, erm, it was still working. This platform plays with your mind :-)

    Friday, January 20, 2017 11:26 PM
  • User258 posted

    @DavidDunscombe said:

    @void said:

    I've played around with using SkiaSharp for rendering controls in a couple of ways, its certainly a quick library.

    I while back i had a go at porting Xamarin Forms to the Raspberry PI using SkiaSharp (https://github.com/roceh/Xamarin.Forms/tree/skia) it actually ran quite well using a non accelerated pure frame buffer (with what few controls i ported) so I've no doubt GPU accelerated SkiaSharp Xamarin Forms running on Android/iOS would be quite snappy.

    I also did a partial SkiaSharp xaml layout container which I've used primary for complex viewcells for performance reasons on Android (https://github.com/roceh/MycoLayout), I was surprised it was faster (as it creates and destroys bitmaps at a fair rate), but the multitude of views on complex layouts that Xamarin Forms Android creates and the interop costs surrounding all that really hurts performance. One of the reasons the May update looks really hopeful.

    Cool stuff. Thanks for sharing!

    XF has been plagued by instability from the get go. I've come to believe that this will continue for architectural reasons. The XF abstraction footprint on the platforms beneath are simply to big. Crack ans crevices will form every time the platform expands, changes og moves - and developers will complain. Adding new platforms will only make the problem bigger.

    Make no mistake, I'm here to stay. But I do hope that Xamarin will be looking at initiatives like flutter.io and your links.

    Saturday, January 21, 2017 10:04 AM
  • User113114 posted

    @PaulVipond said: @BjornB Interesting tip on ModernHttpClient thanks. I'm using MvvmCross and had this defined as part of my IoC setup:

            Mvx.RegisterType<HttpClient>(() =>
            {
                return new HttpClient(new NativeMessageHandler());
            });
    

    So removed new NativeMessageHandler() from the constructor and yay - it starts working in release mode. I commented it back in to check that was definitely the issue and ... you guessed it, erm, it was still working. This platform plays with your mind :-)

    Try deleting bin/obj manually between debug/reease builds, maybe somtehing caches. The framework is getting better day by day. I remember when i thought maybe the temeperature of my coffe had something to do with with my app getting build errors or not, that was 2 years ago.

    Sunday, January 22, 2017 1:50 PM
  • User130 posted

    @DavidDunscombe said: Great to see the focus on performance, android especially could use some improvements. Its a shame you don't offer the easy ability to just AOT selected assemblies instead of the entire app, from my experiments hacking at the msbuild files you really only need to AOT the main app assembly and a couple of xamarin assemblies to get improved startup and performance on android. AOT adds bloat to the already large apk, so some sort of UI to select which assemblies should be AOT'd would be nice.

    The Android team has considered and continues to consider AOT for selected. We'll be glad to have all options at our disposal.

    Improvements in that area are likely to be coming, but discussing that further is both outside the scope of my present knowledge and the focus of the Xamarin.Forms Feature Roadmap.

    Talking of bloat, xamarin currently stores the assemblies uncompressed in the APK, where as with the enterprise version of xamarin you bundle them into a native lib (which gets compressed). Why not compress the assemblies in the non enterprise version - i'm not bothered about the additional 'security' of bundling, but would like the smaller APK size.

    I agree, would be nice to have compression for everyone. I really don't know the historical reasoning behind that. I'll pass that feedback along.

    Monday, January 23, 2017 1:48 PM
  • User216219 posted

    @DavidOrtinau WRT performance, I've been looking at the Evolve 2016 Xamarin Forms app. It takes 11 seconds to load on my Note 3 and 16 seconds on my Zen Max Pro. I know the XF performance gains aren't set to materialise until May, but do you have any indicative stats? I.e. likely to load 25%, 50% faster etc? It would be really helpful to know, as my app is fairly straightforward and to deliver android first and then iOS without much rework in XF would be fantastic.

    Tuesday, January 24, 2017 7:31 PM
  • User141987 posted

    I'm so excited for may 2017 now can't wait for the Xamarin.Forms Embedding Feature that's going to amazing! Now if we can get a drag and drop xamarin forms UI designer that would be epic!

    Keep up the great work Team Xamarin!

    Tuesday, January 24, 2017 7:40 PM
  • User130 posted

    @PaulVipond said: @DavidOrtinau WRT performance, I've been looking at the Evolve 2016 Xamarin Forms app. It takes 11 seconds to load on my Note 3 and 16 seconds on my Zen Max Pro. I know the XF performance gains aren't set to materialise until May, but do you have any indicative stats? I.e. likely to load 25%, 50% faster etc? It would be really helpful to know, as my app is fairly straightforward and to deliver android first and then iOS without much rework in XF would be fantastic.

    I don't have that yet. When we do I'll share the results.

    Wednesday, January 25, 2017 3:53 AM
  • User179286 posted

    When will we have Forms decoupled from a certain Android library version? The inability to upgrade to the latest Android library makes it impossible to use the latest Version of the Firebase Messaging Libraries which may solve my problems. Currently I'm excatly in the same position as @Firefly and my client gets nervous

    Thursday, January 26, 2017 9:25 AM
  • User130 posted

    @ThomasBurkhart said: When will we have Forms decoupled from a certain Android library version? The inability to upgrade to the latest Android library makes it impossible to use the latest Version of the Firebase Messaging Libraries which may solve my problems. Currently I'm excatly in the same position as @Firefly and my client gets nervous

    It's coming. See: https://github.com/xamarin/Xamarin.Forms/commit/fb024a6e62363af2b14e704c0559eb7a2f08c082

    Thursday, January 26, 2017 2:25 PM
  • User311 posted

    @DavidOrtinau People have been whining about this for years now. If this commit is what it took, well, shrugs head.

    Keep up the pace!

    Friday, January 27, 2017 7:05 AM
  • User126992 posted

    I still don't see any major activity in the XF GitHub repo on the performance. There have been some small tweaks, things which could have been fixed a year ago if someone dedicated some time.

    The XF team continues to be very very small, like 6-7 people. You can see the number of commits to master for the 10 last months, since XF became open source: https://github.com/xamarin/Xamarin.Forms/graphs/contributors Many thanks to Adrian Knight, a free contributor, he has done a lot of fixes. You can figure out yourself how many commits per month each member has...

    From my point of view the roadmap should be very focused on 3 main parts:

    1. Fix ALL bugs in controls. As an example, it's not OK that ListView is still not working properly. There are still issues with computing the layout(measure and position) of controls

    2. Focus on performance: measure & tweak performance on the layout engine and the built-in renderers, data-binding performance, XAML performance.

    3. Make sure all small but basic & useful features from Windows XAML are present in XF too. As an example, there are features missing in binding, there's no FallbackValue or NullTargetValue(I saw a recent commit from a contributor but it doesn't look promising, not sure).

    Focus on Android and iOS only. Reality is Windows mobile is pretty much dead right now(even Microsoft pulled the plug for its own apps). For now, Android and iOS is what really matters. I don't think support for Mac OS is important now, when mobile is not working properly. Also, I left out things like XAML previewer and other stuff.

    XF still doesn't look like a good option to produce quality mobile apps. Buggy and slow.

    Friday, January 27, 2017 7:24 PM
  • User130 posted

    @rogihee said: @DavidOrtinau People have been whining about this for years now. If this commit is what it took, well, shrugs head.

    Keep up the pace!

    That commit represents a lot of conversations, evaluating priorities, and negotiating with several moving pieces. That commit was the easy part.

    When managing something like Xamarin.Forms that's used by so many people, what were once small, simple decisions become complicated and of much greater importance. :)

    Friday, January 27, 2017 8:07 PM
  • User130 posted

    @DonBox said: I still don't see any major activity in the XF GitHub repo on the performance. There have been some small tweaks, things which could have been fixed a year ago if someone dedicated some time.

    The XF team continues to be very very small, like 6-7 people. You can see the number of commits to master for the 10 last months, since XF became open source: https://github.com/xamarin/Xamarin.Forms/graphs/contributors Many thanks to Adrian Knight, a free contributor, he has done a lot of fixes. You can figure out yourself how many commits per month each member has...

    From my point of view the roadmap should be very focused on 3 main parts:

    1. Fix ALL bugs in controls. As an example, it's not OK that ListView is still not working properly. There are still issues with computing the layout(measure and position) of controls

    2. Focus on performance: measure & tweak performance on the layout engine and the built-in renderers, data-binding performance, XAML performance.

    3. Make sure all small but basic & useful features from Windows XAML are present in XF too. As an example, there are features missing in binding, there's no FallbackValue or NullTargetValue(I saw a recent commit from a contributor but it doesn't look promising, not sure).

    Focus on Android and iOS only. Reality is Windows mobile is pretty much dead right now(even Microsoft pulled the plug for its own apps). For now, Android and iOS is what really matters. I don't think support for Mac OS is important now, when mobile is not working properly. Also, I left out things like XAML previewer and other stuff.

    XF still doesn't look like a good option to produce quality mobile apps. Buggy and slow.

    Hi @DonBox, thanks for the feedback! It sounds like we are on the right path then, focusing on quality (bugs) and performance.

    In terms of the Feature Roadmap items you noted:

    • XAML - we want to continue to improve features here. If you'd like to see a binding enhancement like those you mention, please add a proposal in the Evolution forum.
    • Android and iOS only - there world is a big place, and it includes not a few companies that have made significant investments in Windows Phone and increasingly in UWP. We will continue to support and improve those experiences.
    • Forms (Xaml) Previewer isn't a product of our team, it's actually the Designer Team. I've been testing the updated builds and it's improving every time. It's going to be a really useful productivity tool.
    Friday, January 27, 2017 9:39 PM
  • User126992 posted

    Come on David...

    Friday, January 27, 2017 10:09 PM
  • User125713 posted

    @DavidOrtinau - It's February 1st now, any updates on the Feb perf/other release?

    The Github commits did not look very promising so I hope there's some secret branch somewhere with all the promised Feb perf fixes.

    Wednesday, February 1, 2017 7:10 AM
  • User221964 posted

    @TonyD

    I understand how you're waiting it, because same here. But as developer, due date is something that can't be stable. I believe you also know it already. I bet they are actually working really hard to archive it.

    Wednesday, February 1, 2017 12:52 PM
  • User3516 posted

    Looks like there is a new release 2.3.4-190-pre2 that includes the fixes for Xamarin.Support.* v25, but its not un nuget yet:

    https://github.com/xamarin/Xamarin.Forms/releases/tag/beta-2.3.4-pre2

    Wednesday, February 1, 2017 5:41 PM
  • User43 posted

    @DirkWilhelm: Worth noting that you can still use the package, even if it's not on NuGet (at the moment). Just download the .nupkg, add a custom NuGet source to a local directory, and add it to your project. :smile:

    Wednesday, February 1, 2017 7:00 PM
  • User130 posted

    @TonyD said: @DavidOrtinau - It's February 1st now, any updates on the Feb perf/other release?

    The Github commits did not look very promising so I hope there's some secret branch somewhere with all the promised Feb perf fixes.

    There are performance updates in the current pre-release, and we're continuing to work on more. We have been most recently collaborating with other teams internally to identify additional opportunities for improvements. We will be spiking on some of those ideas in the coming weeks to see what can be gained.

    Keep an eye on the blog tomorrow. I have a post coming that'll be of interest to anyone tracking the very latest about Forms.

    Please re-read the disclaimer in the initial post. The Roadmap is to give visibility to what we are working on and when we anticipate being able to deliver. Things will and have changed since I shared the roadmap at the beginning of January, and as such I'll be updating it within the next week with the latest information.

    Friday, February 3, 2017 4:02 AM
  • User130 posted

    @BBright said: @TonyD

    I understand how you're waiting it, because same here. But as developer, due date is something that can't be stable. I believe you also know it already. I bet they are actually working really hard to archive it.

    The team is working hard indeed! I can definitely vouch for that.

    Thanks for the support.

    Friday, February 3, 2017 4:05 AM
  • User130 posted

    Hi All,

    I've just posted an update to the Roadmap. Please give it a look. You'll see some things have shifted, and I've adjusted the time windows within which we hope to release.

    I anticipate not everyone will have a ringing endorsement for some changes. With a fantastic, active community as large as ours, we are bound to have some competing priorities. This thread is the place to discuss and advocate for what is important to you. And I sincerely welcome that discussion.

    Please feel to reach out to me directly as well. Direct message me or Slack me.

    If you have something you want to see done, create a proposal in the Evolution Forum. We're accepting proposals and merging PRs all the time.

    On a related note, there are currently a handful of Accepted Proposals in the Evolution Forum. If there's one you like, comment on it and we'll work on getting you assigned to it.

    Since I joined last month, I've been talking to many of you and many of our Xamarin.Forms customers. Your feedback is a major factor that helps guide us. Keep it coming!

    Friday, February 10, 2017 9:39 PM
  • User66766 posted

    @DavidOrtinau thanks for the update. I am disappointed to see how far out the performance improvements have been pushed.

    Friday, February 10, 2017 10:13 PM
  • User7082 posted

    What about universal custom keyboards? I've noticed in the world of hashtags and @ symbols, its quite difficult to get the keyboard to universally display these. Instagram seem to have changed the 'return' button to the @ and hashtag.

    Sunday, February 12, 2017 1:45 PM
  • User299480 posted

    @DavidOrtinau who is responsible for the decision to push back perf improvements that far out? And who do we talk to to get this moved back to #1? Our team opened this bug 9 months ago, and sent no fewer than 20 support e-mails and communications and we've been getting "the team is working hard on this" excuse for the past 9 months. It has been repeatedly pushed out month after month, with zero improvements on the XF side. Why?

    We've moved a lot of our code to custom renderers but short of dropping XF entirely there is nothing more we can do on our end. We've cut a bunch of features from Android for being too slow (while the iOS ones are fine), and we've even disabled all pre-2013 Android phones. We have to deal with 150,000 users complaining about Android perf every day, and it's beginning to cost us a lot of money. I don't think features like "bindable pickers" or "onidiom support" that somehow made it into 2.3.4 are even close in priority. Our perf monitor shows 3:1 UI performance between iOS and Android which is ridiculous.

    So please, point me to whoever is behind this decision so that our team can escalate up their management team and get this resolved. If devs are giving you the run-around, then please point me to their dev manager so I remind him his devs have been "working on this" for nearly a year and haven't delivered anything. I think the XF team might be out of touch with how serious a problem that is. Our team will be happy to spend the next month on the phone or e-mail reminding them of this.

    Sunday, February 12, 2017 7:57 PM
  • User130 posted

    @Jay_UK said: What about universal custom keyboards? I've noticed in the world of hashtags and @ symbols, its quite difficult to get the keyboard to universally display these. Instagram seem to have changed the 'return' button to the @ and hashtag.

    That's a good use case for a Routing effect. On iOS it looks like Instagram uses UIKeyboardType.Twitter. I'm not sure offhand what the equivalent is on Android.

    Perhaps you have more in mind when you say "universal custom keyboard". If so, you may want to open a proposal on the Evolution forum.

    Sunday, February 12, 2017 8:01 PM
  • User243988 posted

    @DavidOrtinau @JLews That's a wonderful reminder of what's really important from the whole roadmap list. I love this reality check. Without performant XF, you're leaving people out there in the wild without any help. It's cruelty to even mention other points being important - really, nobody cares. Fix the important thing please. Hire 5x more people to work on XF and you'll see quickly it will give you wonders - Xamarin needs performance to be even an option for millions of companies. I back up JLews 100% - the amount of issues silently dropped by the support is just astonishing.

    Sunday, February 12, 2017 8:06 PM
  • User130 posted

    Hi @JLews, you can talk to me and this is a great forum to do so. You can also message me directly anytime and I’ll do my best to reply in a timely fashion.

    Our goal is to deliver quality, performance, and features when they are ready. The roadmap is visibility into the windows of time when we anticipate being able to deliver.

    In addition to Bindable Picker and OnIdiom, the Startup Improvements and XAMLC enhancements were initially listed for 2.4, but we are able to release then with 2.3.4 because they were ready in time to go through the pre-release process. Those are performance improvements.

    What we have now is the second iteration of the roadmap. Obviously, things have and will change. What hasn’t changed is our commitment to visibility and communication. When it comes to making decisions about what we will focus on, this feedback and these discussions are all ammunition for me to make a strong case when aligning our priorities.

    Our team opened this bug 9 months ago, and sent no fewer than 20 support e-mails and communications and we've been getting "the team is working hard on this" excuse for the past 9 months. It has been repeatedly pushed out month after month, with zero improvements on the XF side. Why?

    I will follow up on this Monday. Please send me some specifics to track down.

    I think the XF team might be out of touch with how serious a problem that is.

    They are not, however that really doesn’t matter until we can ship you results. We are hearing reports of 2x startup time improvement on Android in 2.3.4. I realize there’s much work yet to be delivered overall on Android, but progress has been made.

    Sunday, February 12, 2017 8:35 PM
  • User67129 posted

    Are the dates outlined an estimate for the "Start" "Middle" or "End" of that quarter?

    e.g. does 2.4.0 - Est Q2 2017 mean April, or July?

    Monday, February 13, 2017 9:19 AM
  • User66766 posted

    @DavidOrtinau the performance improvements should be top priority. FastRenderers, less view creation etc. Every view on Android is wrapped in a ViewGroup which is not necessary and creates 2 views per control. We have been asking for this for a long time.

    Monday, February 13, 2017 3:09 PM
  • User113114 posted

    @DH_HA1 im with you on this one. I think a lot of XF users are aswell. If were to vote between new features vs performance I think we would know that answer.

    Monday, February 13, 2017 3:44 PM
  • User66766 posted

    @BjornB if they use https://github.com/facebook/yoga as the engine for FlexLayout then we might see some layout performance gains.

    I believe the FastRenderers will reduce the number of views created. This is esp crucial for Android

    Monday, February 13, 2017 4:18 PM
  • User11530 posted

    After migrating from native apps to Xamarin platform we are now looking to migrate to something else, probably React Native. Reason: Android performance mostly. It is simply not acceptable and I cannot recommend Xamarin right now to anyone targeting Android only or Forms.

    Monday, February 13, 2017 7:02 PM
  • User207452 posted

    Great to see a roadmap! I would love to see some day in roadmap:

    • Xamarin.Forms for Web/WebAssembly
    • Drag&Drop like Blend designer
    Monday, February 13, 2017 11:33 PM
  • User130 posted

    @ToniPetrina said: After migrating from native apps to Xamarin platform we are now looking to migrate to something else, probably React Native. Reason: Android performance mostly. It is simply not acceptable and I cannot recommend Xamarin right now to anyone targeting Android only or Forms.

    I'm sorry to hear that! I hope you'll give it another look as Xamarin.Forms releases the performance improvements for Android that we have on our roadmap.

    If you're targeting Android only, I'm curious why Xamarin.Android isn't working out for you also. I'll shoot you a direct message to follow up.

    Tuesday, February 14, 2017 12:17 AM
  • User139040 posted

    @ToniPetrina Toni, have you considered late loading some views that don't need to be seen immediately? For instance like the bodies of tab views and such so that they are loaded on demand rather than at app or view startup? It might be easier to do that now than switch to a new framework.

    Thursday, February 16, 2017 3:27 AM
  • User11530 posted

    @"BradChase.2654" The layouts are so simple and it would be easier to go native rather to try twisting this UI to make it work properly.

    Thursday, February 16, 2017 10:27 AM
  • User57869 posted

    I'm longing for the performance enhancements as everybody else, but I thing you're a bit unfair here.

    Xamarin cannot release those improvements when they are not finished. Rewriting the whole rendering/layout system is a big task. But unfortunately this is a task where you need to have much insight of how everything works together. So even if they would push 20 more developers on the project, they would not be finished faster because those new devs would have no clue what to do.

    I'm sure you all worked on a project which was behind schedule. Did your bosses also call the developers or their managers every few minutes? Did that improve your performance?

    We asked for a roadmap for years and now that we have it, you complain again. There will be delays. Delays are normal.

    If I had something to say, I would move more exisiting Forms devs (no new ones) to work on the performance improvements. Rui works on XF for Mac which is completely useless IMHO. Mobiles and desktops need different UI so why should they share the UI code? But Rui could help with the performance improvements. I don't know what the others do currently. New developers could work on new features or test automation. Thats something where they should not clash with and slow down the others too much. Actually I thought that Microsoft would put more resources to XF when they bought Xamarin, but unfortunately that did not happen.

    Thursday, February 16, 2017 12:56 PM
  • User250320 posted

    The question I keep asking myself (and this may answer the last part of what you said Michael) is why MS isn't putting all of Xamarin in to legacy support mode and focusing on taking UWP and .NET core and porting both of those using what they got out of Xamarin to build one system with Windows being the premiere support and Android and iOS coming along for the ride with EXACTLY the same syntax etc.

    We already know this is possible with the .NET framework minus UI. Doing .NET Core will be easier and with .NET Native around, if they built out the tools they could have everything doing native compilation with linking with a tiny runtime.

    So what's left is UWP, which the XAML is VASTLY better than AXML from Android and Xamarin Forms. If MS can create a rendering engine for both Android and iOS that will render real XAML to both platforms they would have a MASSIVE win, and Windows would become the first class citizen.

    Doing so on Android is relatively easy. They could use Unity (or similar) to actually draw the entire thing and make it look like Material Design and be hardware accelerated just like UWP is. You'd actually end up with UWP apps being faster than java apps on Android are today.

    iOS is the tricky one because Apple would no doubt push back on this type of scheme so MS would likely have to use iOS native controls and do layout, but since you can get very similar results (even though iOS's layout system is vastly more difficult to use) it's obviously doable with XF. The issue is that UWP supports way more, especially in the skinning department than iOS does so iOS apps would look basic compared to what you could produce for Android and Windows. But that's a selling feature to MS.

    If MS then created compile farms in Azure for iOS with emulation etc. then no one would ever have to use a Mac for anything which would be a massive win for Enterprise especially and all of those companies that have outsourced Mobile development for exactly this reason.

    The difficulty would come in the edge cases like encrypted DRM video etc. but the underlying platforms are pretty close in functionality at this point so doing what XF does with the custom renderers should be straight forward.

    If MS demoed this and showed say the Windows 10 Email and Calendar app ported with almost no code changes to Android and iOS they'd have a win. Even if the first version was just Android and windows and you had to build iOS separately they'd have a huge win based on market share.

    So if the sane gods of Microsoft are thinking logically it could explain a great deal about what's going on at Xamarin lately. It would also chart a course to where MS can win back the developers and that is the key to long term success.

    Thursday, February 16, 2017 1:07 PM
  • User139040 posted

    @MichaelRumpler I agree that mistakes were made, I think developers got a little crazy wanting to add new features, management never recognized the goals, and then they walled themselves off from the community. They took their eye off the prize. BUT it seems they are changing that and I believe we have to give them a chance here. I am noticing a huge amount of response to the community as well as alot of our long-standing bugs being fixes. I mean bugs that have been a show stopper for some for a year. That's good stuff! That instills confidence. But it can't happen over night. Not everyone can do that rendering code, not everyone can think through the trees and find the gaps in speed. So let's give them time.

    On the handhand I don't agree with the Mac. Our app looks and now behaves like a beast on UWP. Our product has to be on Mac because of legacy users that are on silverlight. So yea Mac is very important to us. We have already put in custom renderers or new controls and solved our droid performance problems so that's not a large concern for us right now but I think it should remain top concern for xamarin so I don't agree pushing that one back.

    Thursday, February 16, 2017 2:46 PM
  • User139040 posted

    @"JamesHancock.1360" you know it's not hard to write a custom renderer using Xamarin for MonoGame right? Then all you need to do is create custom styles for each os. And boom you have an extremely performant UI. I just used sprite batches to do it with xamarin's xamlc code. Well modified so it was less reliant on their internal stuff and instead interfaces.

    Thursday, February 16, 2017 2:51 PM
  • User250320 posted

    @"BradChase.2654" I'm not complaining about speed. I'm stating that the fractured nature of Xamarin right now doesn't actually help anything.

    MS needs a central vision that brings XAML everywhere. Having XF "XAML" and UWP XAML and WPF XAML isn't useful. Having .NET half-baked into iOS layout and AXML (google's rip off of WPF XAML) doesn't really move the goalposts ahead either.

    To put it succinctly MS is fighting a 2 front war: Developers MUST use a Mac to build iOS apps. AND they MUST use javascript to develop for the web. They CAN use a Mac to build for Android. And you CAN use javascript to build for Web, iOS and Android (and even UWP) with a single developer knowing only one language.

    But to be a .NET developer you can use Xamarin on a Mac and get Mobile, and then you still need to know Javascript which you'll do on a Mac too. If you are a .NET developer on Windows, you have to have a Mac, you have to go back and forth between the two, and you have to still know Javascript/Typescript and endlessly fight both systems to work.

    MS MUST change the playing field by providing a new unique value proposition: Write in .NET and XAML and have it run everywhere. That must be ONE version and only ONE version of XAML. UWP XAML. To do this they have to give us virtual Macs that we can compile against. They have to unify XAML and make it run as fast or faster (not hard on Android) as the native tools.

    They also have to make XAML and .NET compile to javascript and HTML.

    All of these things are proven to work (there are several projects for XAML/.NET to javascript/HTML that work pretty well (and typescript is the poster child for compile to javascript which is MS) and MS doing it would solve most of the rest of it and making EDGE just natively (without a plugin) and IE with a plugin (silverlight .next for backwards compatibility runtime that even worked on Windows 7) would provide a massive leg up.

    You once again could be a .NET guy and never need to know another language which is what businesses, especially small shops are looking for. One or two javascript guys can do everything in a small company. But with a hybrid .net environment you still have the javascript guy and you still have the mac. So the costs are significantly higher even though the product might be better (and xamarin isn't better than native right now as the comments above clearly outline).

    Imagine if you could write one app with a few transforms for customizations on each platform, and hit compile and it generated iOS binaries, Android binaries (faster than java and almost on par with C++), UWP binaries for Desktop, Mobile, Xbox and hololens, and a full web experience that didn't feel like a plugin because it compiled to HTML and javascript all in one shot?

    If you could, then you'd get people building WWWs as well as SPAs in UWP. You'd get developers off of Macs and back on Windows. You'd make Windows a first class citizen again while eliminating the cost gap between pure javascript with node and nativescript/react and .NET hybrid and you'd get the market back.

    But that can't happen with a fractured approach of keeping Xamarin separate creating their own dialects. And even if you got mobile and desktop in one, you still have web. But if you build the engine so that it can compile down using roslyn to ALL of them then you win.

    And honestly I'll take XAML + C# over HTML + Javascript any day. But what I and a ton of other developers won't do is waste endless hours trying to make windows talk to a mac and still have to have the damn mac there all to just use C# when I could be using NativeScript or React and Nodejs instead of .NET in the backend. Why would you when one skill can transfer across EVERYTHING versus endlessly fighting to use C# for anything other than backend code right now (or irrelevant UWP apps that no one uses)

    .NET Standard is an excellent start to this. If they created .NET standard that could also cross compile to javascript so that you could share code across all platforms (DTOs, client HTTP Rest libraries etc.) then it would be straightforward to build wrappers that worked like Xamarin Forms does now, but against the .net core runtime instead of mono. Further compiling XAML down to HTML and Javascript is a solved problem (see many projects online) and we know the same is true for android and iOS because of Xamarin Forms. So creating a unified framework that works on all of these fragmented platforms using one language: XAML for UI integrated with C#/.NET in the backend is the value proposition that MS needs to be presenting at BUILD.

    Not more Xamarin half-measures.

    Thursday, February 16, 2017 3:15 PM
  • User76049 posted

    @JamesHancock.1360

    Easier said than done though, we have massive greenfield dev of a desktop app, quite frankly currently only WPF can do it, with UWP we'd be in trouble. Problem is, how do you give the power it has going cross platform with .NET standard?.

    Getting our new Xamarin Forms mobile framework onto UWP has been a bit painful but it's still a pretty good result with a high degree of code reuse and three platforms supported from one (seriously overworked) developer

    We were:

    Mobile: (iOS, Android and Windows mobile) C# Desktop WPF C# - (seriously big app, 7-+ modules, 1000s of screens) Web: MVC C#/Javascript UWP: Ignoring it except via Forms, Microsoft are throwing the kitchen sink at it but to me (and many other devs) it's a serious questionamrk for large scare LOB system development, I just see smaller apps pushed out in UWP despite all the shouting (maybe @DavidOrtinau has some input on UWP in this regard)

    .Net standard has already been pushed back to Q3 2017 from Q1 2017.

    The mac thing, as long as Apple are as difficult as they are regarding getting software onto their platform, I don't know how easy that will be to overcome, this is a war between Google, Apple and MS after all.

    I'd like to see a unified XAML UX approach as well across all platforms but I'm a realist and it's going to a while before that appears, seeing 85-90% code reuse and hitting three platforms isn't a bad start though thanks to Forms.

    Thursday, February 16, 2017 3:30 PM
  • User139040 posted

    @"JamesHancock.1360" I didnt mean to insinuate you were complaining. I think people have a right to be a bit upset with how long the issues have gone on(not saying you just in general). As for us, we have one code base in C# without a lick of objective C, HTML, Java, or Javascript and we hit all platforms except Mac(forms shortly right?). I cant complain about that! Yes there were alot of hickups to get there, yes iOS runs the second fastest now to UWP, and Android is way in the back(to be fixed soon). But we made Android work faster by the way we built our controls and then iOS and UWP both got those improvements without us having to write an extra line of code. Thats pretty damn neat. BTW with your idea its funny a little known Microsoft employee built something called ScriptSharp (C# to Javascript), his name is Nikhil Kothari (amazing guy btw). BUT it seemed under the magical Balmer reign that they just didnt care about it. So he works at Google now.

    Thursday, February 16, 2017 3:41 PM
  • User250320 posted

    @NMackay .NET Standard is part of .NET Core 1.0. I'm using it right now. VS.NET 2017 has it built in and it's working just fine. What's delayed is .NET NEXT that is .NET Standard 2.0 which is additions to .NET 4.6.2.

    Look at what you're actually using there. Meanwhile you could use NativeScript and replace all of your Mobile, Web and UWP work in one shot with one language. This is the microsoft problem.

    The first step is to merge Xamarin Forms into UWP and get rid of the custom dialect of XAML that should never have been created and then backport a ton of features of UWP XAML to Xamarin Forms.

    While that's happening the rest of the Xamarin team not working on maintenance mode and everyone else MS can spare should be working on porting .NET Native, .NET Core and UWP rendering to Android.

    Bridge.net already exists. MS should evaluate and buy it and integrate it in for web deploy while the Xamarin crew are integrating everything.

    I agree iOS is a problem. MS has a wonderful thing called Azure though. Put a f-ton of Mac minis in a closet somewhere and then provide compile and emulator services from that cluster for free to any MSDN subscriber. Boom! No Mac required.

    @"BradChase.2654" The problem is that you've still got custom dialects running around all with their own gotchas. It's a complete mess when you actually look at it. Then go and use NativeScript or React. None of that AND you get to use the same language you're writing your web stuff in. That's what MS is ultimately fighting and this Xamarin over in it's own corner doing it's own thing isn't going to cut it. One plan, one vision just like the Windows 10 kernel everywhere is what it's going to take to get this back on track, because that's what the competition did with nodejs and that's why MS is behind.

    Thursday, February 16, 2017 3:46 PM
  • User250320 posted

    And I might add: If MS did this, everyone with a brain would run to this stack. Why? C# is a real language. Javascript is not.

    And that's why it will work. Increasingly people are starting to realize why Javascript sucks. But until MS gives them an alternative they're making it work.

    Thursday, February 16, 2017 3:49 PM
  • User76049 posted

    @JamesHancock.1360

    NativeScript? No thanks. Lots of devs hate Javascript.

    What would you use instead of WPF for an app that huge? this app has been dev for 18 months.

    Thursday, February 16, 2017 3:49 PM
  • User250320 posted

    On windows desktop you're still screwed if you need Windows 7. You still have to use WPF. If you could target only Windows 10 UWP has very few downsides, especially with .NET native compile possible often.

    But that's also why so many companies are ditching desktop. Pain to deploy and specialized language instead of a single language for development. (For the record I just used Desktop Bridge to bring our WPF app to the Windows store because Xamarin Forms SUCKS with a mouse so it wasn't viable yet whereas Desktop Bridge just worked for the most part.)

    Why build a desktop app when you can do 90% of that in a browser without all of those deploy issues? UWP solves that, and by porting it everywhere it also solves the developer issue having to have specialists when you could have people that can work on anything because it's all in the same language.

    NativeScript is NativeScript, but there is also React, Ionic and many others. You get the point. It's a hell of a lot cheaper to hire 2 good javascript devs than 2 javascript devs and a .NET guy or 2. (i.e. about $120k+ / year cheaper all in)

    When you do that simple math you understand what the nature of MS's problem is and why this half-assed approach isn't going to work.

    Thursday, February 16, 2017 3:54 PM
  • User76049 posted

    @JamesHancock.1360

    They wanted to support update XP and Windows 2000 machines until I put my foot down and insisted they use .NET 4.5.1 so the devs had Task/async :s So yeah, they needed Win7 support.

    I'm slightly skeptical about delivering a modular App that big in UWP (views are massive) but maybe it's okay, it can always be ported over later.

    I totally get your point though.

    Thursday, February 16, 2017 4:00 PM
  • User250320 posted

    @NMackay Imagine if MS created a shim plugin for IE 11 that would allow UWP to run in IE 11 so it would work on Windows 7? Basically create a stripped down RDP that allowed the app itself to run in Azure or a local server and the UI went to the browser window. (or skip IE and just create a player that did the same)

    Then there would be no choice like you had. You could write with the full .NET Core/Native/UWP and still get older systems while it mattered. A variant of Desktop bridge could be used. Obviously the experience wouldn't be as good as native UWP on Windows 10, but you'd get backward compatible while it mattered and could dump old legacy support issues and the deploy issues all at the same time.

    This is what I'm talking about. Yes MS would fear bringing UWP back to Windows 7 because they wouldn't get the upgrades, but guess what? UWP isn't a reason why businesses are upgrading anyhow. And by getting devs up to the latest and greatest (which is why all of the iterations between WPF and UWP didn't work either) without the downsides is FAR more important to Microsoft in the long run than trying to force Windows upgrades through developers complaining about legacy coding when they want to do new stuff.

    The key is that yes, old stuff, web, iOS and Android will have a less good experience. But if it's good enough and the UWP stuff is even better, you'll once again own the developer space, which is all that matters. Everything else is a side effect of that group of people making choices. Right now they're making choices that hurt MS. This is how MS turns that around.

    Thursday, February 16, 2017 4:06 PM
  • User250320 posted

    Oh, and let us write XAML in JSON (JAML anyone). Lots of devs have never had to write xml at all and JSON is way easier to read even though the result is the same and parsing it is as fast or faster than xml so shouldn't be a big deal to add.

    Thursday, February 16, 2017 7:22 PM
  • User125713 posted

    @DavidOrtinau @JLews

    We are seeing the same thing and we are also using as many custom renderers as possible. I am actually attaching our prod results for this week.

    Page # times rendered iOS UI rendering(ms) Android UI time (ms) Android UI time (no CR)ms Discussions Rendering Time 8335 173 382 521 Matches List Render Time 39157 50 261 344 Matches Stack Render Time 43303 327 836 1309 Messages Rendering Time 143164 26 365 588 Visitors List Render Time 41096 13 74 133

    Right most is no custom renderers (no CR). Middle one is current (partial custom renderers for low-cost effort items). However, we can't move everything as that means completing dropping xamarin forms and we have thousands of LOCs in it already. Our app is tinder-like so users swipe through pictures with text underneath. Imagine how frustrated you'd be if you the UI froze for 836ms on average between every pic.

    Our team opened bugs 41863 and 42235 back in June 2016 and nobody's touched them.

    I'd be happy if you even took it in smaller steps but we really need to see some progress now otherwise we are also very disappointed with how XF has handled perf. Maybe deliver fast renderers for just a couple of views in week 1, then more in week 2 etc. But really show progress or deliver something. Please discuss this with your team again and come up with a more aggressive plan - also, our team is mostly based in Redmond so if you need us to persuade someone in MSFT to give you more resources, or re-prioritize this we might be able to reach out to some of our contacts there and explain this whole situation.

    Judging by how many "likes" JLews' post got I think most the community agrees that if you are going to fix only one thing in XF, Android perf should be it.

    Thursday, February 16, 2017 8:56 PM
  • User64909 posted

    @DavidOrtinau said: @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!

    Very excited to get performance upgrades. Hoping to get it soon.

    Friday, February 17, 2017 4:22 AM
  • User221964 posted

    @MichaelRumpler

    I agree with that.

    It is a big task. The most important one when they release new update is stability. Stability and advance the date can not be together.

    And I understand why Xamarin can't move all the member to performance. I think, Xamarin also would want if it was possible. But every member has a different ability and expertise. Moving more people does not always guarantee a better result.

    Friday, February 17, 2017 5:00 AM
  • User130 posted

    @TonyD @Abhijeet_Surya performance, yes! One of the main benefits I like about our nightly builds being public is we can see that work (however small and incremental) happening over time and get feedback as early as possible.

    re: bugs that haven't seen ANY updates -- to say we have room for improvement here is an understatement. Expect to see increased communication and velocity here in the coming weeks.

    Saturday, February 18, 2017 2:19 PM
  • User166943 posted
    1. revert to wpf naming and redo everything one on one that this framework do like important datatype on datatemplate that you are missing etc..
    2. make it work perfectly over wpf on windows 7
    3. stability
    4. performance

    do this in your next 6 months to 1 year and xamarin might actually work. Most wpf coders are currently re-orienting themselves at the moment but i'm really not sure they will go into another messy MS bandwagon.

    at moment, you look like a team of javascript coders to me. did you ever code in wpf or what? i'm starting to really wonder if i should switch to swift, ios and give up multiplatform coding...

    so many years lost on MS never ending beta crap & always buggy UI frameworks, so many f. years and now you come along and change the naming and how everything work just to spit in our face hahahahaha wtf..

    after so many failed versions of wpf and silverlight etc..

    you decided that you prefer your own useless naming and weird layout system because you clearly never coded in WPF, lived what we have live & now you're thinking about CSS because of "selectors" hahahahaha .. another proof you have no ideas what you are doing.

    only reason i'm using XAML is because it's not CSS and HTML. You understand that more UI options will just bring a codebase mess!! right? some will prefer css, other styles, other in code etc.. of course you are not the one who have to work on those crazy messy codebase

    xaml language should be in a better clearer DSL language than XML but that's about it.. functionally it should be mostly more of the same.

    i've been coding all my life and truly, the worst part of coding is that you're always stuck in a world of idiots and juniors in high positions who take stupid decisions who affect everything of your work..


    you understand that your xamarin forms render differently on each platforms.. WHY? Can you explain us why this is the standart? no perfectly supported and exactly the same common light and dark theming?

    Most of us want exact 1on1 on all platform.. You understand that yes? that we will have to do a lot just to fix what you didnt want to put the work into doing.?

    we need a 1on1 multiplatform matching theming system and access to ALL the xaml, styling and templates, custom controls etc.. so we can modify,extend it ourselves if and where needed. YOU UNDERSTAND RIGHT? because this is all basic junior stuff.. if you don't you dont know basic stuff like this, you should be fired and they should replace you with a true wpf senior who knows what other wpf seniors working in companies need ..

    Saturday, February 18, 2017 7:41 PM
  • User301146 posted

    By how much do you estimate you will be able to improve startup and overall performance of Xamarin.Forms apps?

    I suggest you create a benchmark page where you compare performance of Xamarin and Xamarin.Forms with native and other cross platform solutions. If performance is good you will definitely convince me and many others to use Xamarin, otherwise not.

    In fact I have already decided that writing native apps is the way to go. Simply because end user experience is the number 1 priority. So if you could convince me with some benchmarks I would be glad, cos I like C# and don't like to learn new languages and maintain code synchronization. Cross platform is the future, but not yet, because of performance problems!

    Sunday, February 19, 2017 9:22 AM
  • User57869 posted

    @"JamesHancock.1360"

    It's a requirement by Apple that iOS development must be done on a Mac. iOS code must be compiled by Xcode and it can only be deployed to an iOS device which is physically connected to the Mac build host. So even if you put the build host in the Cloud (which you can), you cannot deploy to an iOS device connected to your local Windows machine.

    I'm sure somebody at Xamarin (could have) compiled iOS apps on Windows long ago, but they are simply not allowed to.

    I'd love to install Windows on my Hackintosh, but it's Apples fault that I can't and not Xamarins.

    Sunday, February 19, 2017 11:11 AM
  • User250320 posted

    @MichaelRumpler Hence why I said that MS should put a ton of Mac Minis in Azure cloud and do the compiles automatically for us so we never have to use a Mac if we don't want to.

    Sunday, February 19, 2017 2:09 PM
  • User31385 posted

    @"JamesHancock.1360" have you seen https://blog.xamarin.com/mobile-center-webinar-recordings-mobile-center-for-xamarin-developers-and-continuous-delivery/?

    There's no requirement for you to set up your own Mac as a build device.

    Sunday, February 19, 2017 10:01 PM
  • User251799 posted

    @DavidOrtinau said:

    @ThomasBurkhart said: When will we have Forms decoupled from a certain Android library version? The inability to upgrade to the latest Android library makes it impossible to use the latest Version of the Firebase Messaging Libraries which may solve my problems. Currently I'm excatly in the same position as @Firefly and my client gets nervous

    It's coming. See: https://github.com/xamarin/Xamarin.Forms/commit/fb024a6e62363af2b14e704c0559eb7a2f08c082

    David, what are we looking at here? I'm sort of seeing an added dependency on 29.0.0.1 and nothing removed that would indicate that the dependency was gone elsewhere. I'm probably misinterpreting this (I hope ;)

    More importantly: Given that's such an easy fix, can this just be applied to a custom build of 2.3.4 and we would be able to use more recent Google APIs? Not being able to use Google's Place Picker on Android is a serious show stopper for us :/

    Wednesday, February 22, 2017 7:20 PM
  • User130 posted

    @PhilippSumi C9 just went stable today. https://releases.xamarin.com/stable-release-cycle-9/

    To coincide with this release we've updated our NuGet package to 2.3.3.193. This has the nuspec change to support 23+ for Android support libraries. 29+ for Maps.

    So you can use newer. Those are the minimums. Given you are targeting framework 7.0+ on your Android project.

    https://www.nuget.org/packages/Xamarin.Forms/

    Wednesday, February 22, 2017 10:49 PM
  • User251799 posted

    @DavidOrtinau said: @PhilippSumi C9 just went stable today. https://releases.xamarin.com/stable-release-cycle-9/

    Wohooo, this is awesome! Can we expect an updated 2.3.4.* preview soon that also drops the fixed version dependency?

    Wednesday, February 22, 2017 11:29 PM
  • User76049 posted

    Oh cool, a stable XAML preview in VS2015 and a UWP masterdetail that works...no, probably not.

    Wednesday, February 22, 2017 11:43 PM
  • User139040 posted

    @NMackay I agree with the master details. Really needs fixed for UWP. Insane it's taken this long for such a large up front problem and release breaker.

    That said has anyone used the nightlies and see weird dots on all the input controls for Android? What are those and is it a bug or some strange new UI thing? More importantly how do we get rid of them. It's not in 2.3.4 backwards.

    Thursday, February 23, 2017 12:05 PM
  • User76049 posted

    @BradChase.2654 said: @NMackay I agree with the master details. Really needs fixed for UWP. Insane it's taken this long for such a large up front problem and release breaker.

    That said has anyone used the nightlies and see weird dots on all the input controls for Android? What are those and is it a bug or some strange new UI thing? More importantly how do we get rid of them. It's not in 2.3.4 backwards.

    MasterDetail isn't much better in iOS, if you have a contentpage with 2 grid columns, some text in column 0 and a map in column one (each column has 50% available space), swipe right across the map and out pops the master detail. Issue going back to 2014....sigh.

    https://forums.xamarin.com/discussion/19364/map-in-master-detail-stops-swipe-to-open

    Thursday, February 23, 2017 3:39 PM
  • User139040 posted

    NM I figured out the problem in the nightlies on android with the dots. It was the new accessibility stuff. Ill just start making pulls at this point because some issues are getting closed out without being fixed but if anyone needs a quick fix its in ViewRenderer.cs under SetHint().

    Change the line to set elemValue to:

    var elemValue = string.Join( (String.IsNullOrWhiteSpace((string)(Element.GetValue(Accessibility.NameProperty))) || String.IsNullOrWhiteSpace((string)(Element.GetValue(Accessibility.HintProperty)))) ? "" : ". ", (string)Element.GetValue(Accessibility.NameProperty), (string)Element.GetValue(Accessibility.HintProperty));

    Saturday, February 25, 2017 10:00 PM
  • User113114 posted

    Before you update to C9!! Stable C9 cant debug second order PCL projects, bug is filed and confirmed.

    Monday, February 27, 2017 9:50 AM
  • User76049 posted

    @BjornB said: Before you update to C9!! Stable C9 cant debug second order PCL projects, bug is filed and confirmed.

    Thanks for the heads up, that would affect me. Could you post the bugzilla link so I can track it's progress?

    I'm waiting for the 1st or 2nd service pack before updating, same story in Cycle8.

    Monday, February 27, 2017 11:33 AM
  • User113114 posted

    @NMackay said:

    @BjornB said: Before you update to C9!! Stable C9 cant debug second order PCL projects, bug is filed and confirmed.

    Thanks for the heads up, that would affect me. Could you post the bugzilla link so I can track it's progress?

    I'm waiting for the 1st or 2nd service pack before updating, same story in Cycle8.

    I somehow made it private.. maybe i can add you to cc list, pm me email if youd like me to try

    Monday, February 27, 2017 1:03 PM
  • User113114 posted

    @PhilippSumi pre 2 has no dependencies

    EDIT: well it has.. but you are free to upgrade android libs to latest

    Monday, February 27, 2017 1:07 PM
  • User130 posted

    @BjornB said: Before you update to C9!! Stable C9 cant debug second order PCL projects, bug is filed and confirmed.

    This is Visual Studio on Windows, correct? I'm able to debug on Mac, VS for Mac and Xamarin Studio.

    Monday, February 27, 2017 1:56 PM
  • User113114 posted

    @DavidOrtinau said:

    @BjornB said: Before you update to C9!! Stable C9 cant debug second order PCL projects, bug is filed and confirmed.

    This is Visual Studio on Windows, correct? I'm able to debug on Mac, VS for Mac and Xamarin Studio.

    True! Only affects VS on windows

    Monday, February 27, 2017 5:48 PM
  • User76049 posted

    @BjornB said:

    @DavidOrtinau said:

    @BjornB said: Before you update to C9!! Stable C9 cant debug second order PCL projects, bug is filed and confirmed.

    This is Visual Studio on Windows, correct? I'm able to debug on Mac, VS for Mac and Xamarin Studio.

    True! Only affects VS on windows

    This has been a legitimate gripe of mine for a while, too much focus on the iOS version of Studio clearly, Visual Studio for Windows always lags behind for features and stability, it's a fact.

    Monday, February 27, 2017 5:52 PM
  • User139040 posted

    @NMackay I am surprised VS went to 32 bit to be honest. I dont know why they just didnt optimize for 16 bit.

    Monday, February 27, 2017 7:19 PM
  • User113114 posted

    @DavidOrtinau I have tried to find somewhere to download alpha/beta releases so that i can downgrade from stable cycle 9. I cant find any :neutral: Can someone provide a link?

    Wednesday, March 1, 2017 1:10 PM
  • User134292 posted

    @DavidOrtinau

    Any news? We will need a link to downgrade or an Alfa/Beta release with the fix...

    Wednesday, March 1, 2017 2:04 PM
  • User130 posted

    @BjornB @LGMaestrelli there are downgrade instructions on the release notes. Let me know if you are unable to get this working.

    https://releases.xamarin.com/stable-release-cycle-9/

    Upgrading and Downgrading

    You can install this new version by checking for updates on the Stable updater channel.

    You can downgrade back to the previous Cycle 8 Stable versions (from before February 22, 2017) by manually reinstalling each old package. See the “Get the latest stable version of Cycle 8” section on your account page: https://store.xamarin.com/account/my/subscription/downloads#cycle8. (If you do not yet have a Xamarin login, you can create one.) If you have any trouble downloading the previous versions from that link, would like to install an even earlier set of versions, or simply would prefer an email with all the installer links you need, feel free to email contact@xamarin.com.

    Wednesday, March 1, 2017 4:49 PM
  • User113114 posted

    @DavidOrtinau said: @BjornB @LGMaestrelli there are downgrade instructions on the release notes. Let me know if you are unable to get this working.

    https://releases.xamarin.com/stable-release-cycle-9/

    Upgrading and Downgrading

    You can install this new version by checking for updates on the Stable updater channel.

    You can downgrade back to the previous Cycle 8 Stable versions (from before February 22, 2017) by manually reinstalling each old package. See the “Get the latest stable version of Cycle 8” section on your account page: https://store.xamarin.com/account/my/subscription/downloads#cycle8. (If you do not yet have a Xamarin login, you can create one.) If you have any trouble downloading the previous versions from that link, would like to install an even earlier set of versions, or simply would prefer an email with all the installer links you need, feel free to email contact@xamarin.com.

    I cant downgrade to C8 (that is all the instruction says) it will break the android project. I want release 6 of the beta for cycle 9 (stuff worked in this one :P )

    in C9 stable i cant debug. im in a shitty situatuon to say the least

    Wednesday, March 1, 2017 4:52 PM
  • User130 posted

    @BjornB ah, I understand. Let me see what I get.

    Wednesday, March 1, 2017 5:01 PM
  • User130 posted

    @BjornB @LGMaestrelli we're pulling this together. I'll message you directly on the forum.

    Wednesday, March 1, 2017 5:26 PM
  • User134292 posted

    @DavidOrtinau

    Another issue that we found in the Cycle9 is in the XAML editor. In some files it look like the image And when this happens the indentation is broken

    Wednesday, March 1, 2017 8:55 PM
  • User76049 posted

    @LGMaestrelli said: @DavidOrtinau

    Another issue that we found in the Cycle9 is in the XAML editor. In some files it look like the image And when this happens the indentation is broken

    Cycle9 breaks PCL debugging (which happened back in 2015), No support anymore (even for enterprise), good luck.

    Wednesday, March 1, 2017 10:46 PM
  • User134292 posted

    @NMackay

    Take a look at this: https://bugzilla.xamarin.com/show_bug.cgi?id=52760

    Wednesday, March 1, 2017 10:51 PM
  • User125713 posted

    @DavidOrtinau it's now March, can we get a concrete update on the status of perf improvements for Android? I keep checking github and the nightly builds but I still haven't seen any checkins related to perf. Why is that?

    Thursday, March 2, 2017 3:30 AM
  • User81057 posted

    @TonyD said: @DavidOrtinau it's now March, can we get a concrete update on the status of perf improvements for Android? I keep checking github and the nightly builds but I still haven't seen any checkins related to perf. Why is that?

    It tends to be in different branches, they've just committed some android fast renderers code (for button, image and label views) which eliminates the ViewGroup container around views and implements IVisualElementRenderer directly, so hopefully for complex layouts should give a boost to general smoothness & reduced inflate time.

    Thursday, March 2, 2017 7:46 AM
  • User76049 posted

    @LGMaestrelli

    I'm well aware of this issue, hence why we're stuck on cycle8 but at least we can debug.

    Thursday, March 2, 2017 10:17 AM
  • User126992 posted

    @TonyD said: @DavidOrtinau it's now March, can we get a concrete update on the status of perf improvements for Android? I keep checking github and the nightly builds but I still haven't seen any checkins related to perf. Why is that?

    I'd like to know that too.

    What is the concrete \ actual roadmap of the Xamarin Forms product?

    Does the Xamarin Forms team has a concrete\clear roadmap? Can we, devs using Xamarin Forms, see it please?

    This page is just a discussion page on the upcoming features, but what is the actual \ concrete roadmap which the team uses ? Or is it a secret?

    From my point of view, Xamarin Forms development continues on same blurry line.. A lot of promises, teams remains small, nothing changes... I guess it is what it is..

    Thursday, March 2, 2017 2:44 PM
  • User130 posted

    @DonBox this is the roadmap - https://forums.xamarin.com/discussion/85747/xamarin-forms-feature-roadmap/p1

    Evolution Forum also obviously has some discussion of other features that are being considered.

    As it relates specifically to Xamarin.Forms and where it doesn't breach confidentiality with other parties, I think it's fair to say I'm not keeping any secrets.

    As mentioned above, Fast Renderers work is in a branch. We did some work on layout compression as well, but need to address how it's implemented so as not to break other APIs.

    You can pull and run anything on GitHub to check performance. Make sure to do a release build and not debug. When I have some results of our own to share, I will do so.

    Thursday, March 2, 2017 3:14 PM
  • User126992 posted

    @DavidOrtinau So you're saying that for example:

    CSS with FlexBox Support - Feature, Enhancement

    this is something actually on the concrete roadmap for Q2 2017 !? CSS Flexbox?

    Thursday, March 2, 2017 3:17 PM
  • User130 posted

    @DonBox said: @DavidOrtinau So you're saying that for example:

    CSS with FlexBox Support - Feature, Enhancement

    this is something actually on the concrete roadmap for Q2 2017 !? CSS Flexbox?

    Yes, that's on the roadmap. It's slightly different now per the Evolution discussion. I'll update the description on the roadmap.

    A word of caution as you continue to use the word "concrete". I want to make sure I'm setting the proper expectation for you. Please read the disclaimer on the roadmap post.

    Thursday, March 2, 2017 3:51 PM
  • User125713 posted

    @DavidDunscombe @DavidOrtinau can you point me to this branch where those perf fixes are. I checked the main suspects on github and don't see anything.

    Thursday, March 2, 2017 5:53 PM
  • User81057 posted

    @TonyD

    https://github.com/xamarin/Xamarin.Forms/tree/android-fastrenderers

    Thursday, March 2, 2017 6:16 PM
  • User112311 posted

    This is my current view of things in song format.

    Xamarin Rhapsody

    Is this a native app? How would you the performance rate? Caught it in Profiler No escape from a slow UI inflate.

    Open your App Lookup the code and see There is a breakpoint, but it's not being hit Because the Viewgroup can come, the Viewgroup won't go Memory high, Quality low Any way the build goes doesn't really matter to me. to me.

    Xamarin just checked in code Put the method in a thread Didn't try catch now it's dead Xamarin, the exception had just begun But now you've gone and thrown it all again

    Scrum master, oo oo oo oo ohhhh Didn't mean to make you cry If the schedule is not back on time tomorrow Carry on, carry on, as if this project never really happened

    Too late, the meeting has come Sends shivers down my spine Boss is yelling all the time Come on everybody, we"ve got to go Gotta checkin everything and face the review

    Xamarin, oooo ooohhhh I don't wanna debug I sometimes wish I never started coding at all.

    I see a little little monkey making code, Xamarin! Xamarin! Will you compile to Android?

    Code reviews and APIs Bosses will not be happy!

    DE ICAZA! (de icaza) DE ICAZA! (de icaza) De Icaza Help me please!

    RuimarihnOOOooooo...

    I'm just a poor dev, nobody loves me HE'S JUST A POOR DEV, FROM A POOR COMPANY, SPARE HIM HIS CODE FROM CODE REVIEWS PLEASE!

    Nugets come, nugets go, Will you let me code? BCLBuild! No, we will not let you code! XamlC! No, we will not let you code! InitializeComponent! No, we will not let you code We'll not let you code We'll not let you code No, No, No, No Xamarin, Xamarin, (Xamarin, let me code)

    GitHub has a branch that is put aside for speed, for speed, for speeeeeeeeeeeeeeeeeeeeeeeeeeeeeed

    So you think you can make it build in a short time? So you think you can expect us to meet the deadliiine? Oooooh, Ortinau, can't do this to me Ortinau, Just gotta write songs, write silly lyrics about all this

    (ooooh, yeah, ooooh yeah)

    UAT never happens, anyone can see, My app won't happen, Appstore won't accept meeeee

    Friday, March 3, 2017 10:37 AM
  • User271810 posted

    @Irreal I love it, this is great :smiley:

    Friday, March 3, 2017 10:38 AM
  • User134292 posted

    @Irreal Can I get it on Spotify??

    I think is safe to say that most of us, developers, are disappointed with XF

    Friday, March 3, 2017 11:11 AM
  • User299480 posted

    @LGMaestrelli @Irreal I have a lot of respect for developers, so after all this inexplicably wasted time, I'm beginning to think the XF team is intentionally botching and delaying Android perf because Google is a competitor to Microsoft.

    Saturday, March 4, 2017 4:49 AM
  • User103333 posted

    @LGMaestrelli said: @Irreal Can I get it on Spotify??

    I think is safe to say that most of us, developers, are disappointed with XF

    Dude if you are disappointed with XF go to XF's github and make it better! Its open source!

    I've been working with XF since 1.3.0 and I must say things are getting better since then, a lot better, its a great technology, but also complex.

    Some errors are not from XF, are from VS integration for example. Indeed I'd like to see components to be more polished but I know its just a matter of time for that to happen. Meanwhile, relax, try to sing the Xamarin Rhapsody and make your C# skills do the rest.

    Saturday, March 4, 2017 5:14 AM
  • User112311 posted

    I'm glad most people "got" it, but I do wish to clarify anyways that my intention was to have some light hearted fun at the expense of the state of Xamarin.Forms development.

    I would never spend the time if I didn't actually love the framework and the community. It is because I love it so, that I care and would like to see it become even better.

    One of the problems is that we expected big resourced and hugely faster development with the Microsoft buyout and that just isn't there. At least not in a big enough way.

    But we just have to deal with it and continue being a part of this awesome community.

    Saturday, March 4, 2017 8:50 AM
  • User223890 posted

    Our company is really looking for one stop shopping of FORMS on all the major platforms. It's great to see MacOS on the roadmap, unfortunately since over 70% of PC users are still on Windows 7. Supporting MacOS won't be enough for us to move whole hog!!! How soon until we see support of Forms on Windows7. Or is Forms going to stop at UWP?

    Thanks for the great work so far!

    Tuesday, March 7, 2017 9:57 PM
  • User139040 posted

    @RayTrask I believe someone had already started one but appears they have closed it out to start a new version of it. The old PR was here:

    https://github.com/xamarin/Xamarin.Forms/pull/756

    Wednesday, March 8, 2017 3:29 AM
  • User130 posted

    @Irreal said: I'm glad most people "got" it, but I do wish to clarify anyways that my intention was to have some light hearted fun at the expense of the state of Xamarin.Forms development.

    I would never spend the time if I didn't actually love the framework and the community. It is because I love it so, that I care and would like to see it become even better.

    One of the problems is that we expected big resourced and hugely faster development with the Microsoft buyout and that just isn't there. At least not in a big enough way.

    But we just have to deal with it and continue being a part of this awesome community.

    It IS an awesome community! Your post got a lot of love in the office. ;)

    I feel for those who experience frustration and pain, and real business impact. For my part, I cannot afford to stop and dwell there. Instead, I'm working to get you unstuck and moving in a positive direction by all means at my disposal.

    A lot of you are having amazing success with Forms. I hope everyone has a chance to see the Visual Studio 2017 keynote yesterday and the fantastic Xamarin.Forms work that is featured. For anyone that has concerns about investment in the platform, I think that speaks volumes.

    Where we as a team and community can point to any best practices or guidance to avoid pitfalls, let's do that. And where we can influence improvements in performance, stability, and closing feature gaps let's continue doing that.

    All along the way I'm trying to improve communication and transparency. We won't always agree. But we certainly do agree we have a fantastic community, one we owe ourselves to encourage to achieve very best.

    Total bugs are down. New bugs are getting swifter first look and responses. We are eating into the backlog of issues. Communication is up on Bugzilla, to make it more clear what we have reviewed and reporting on status. It's not perfect, and we're iterating. My reports are showing progress I'm very pleased with, especially moving issues from the New status forward (25% improvement weekly). All this results in the engineering team being better equipped to address issues and maximize their time. I believe we'll be seeing better fruits here in coming weeks and months.

    We have several builds in the queue this week for updates to the pre-release regressions, as well as some individual web previews for performance and features. More to come.

    Thanks for indulging me to share a bit. Now back to it.

    Wednesday, March 8, 2017 4:04 PM
  • User3516 posted

    @DavidOrtinau

    i think there is a little error in the roadmap.

    For 2.4.0 - Est Q2 2017 there is 'Deprecation of iOS 6', but the release notes for 2.3.4.184-pre1 say this: '[iOS] Deprecate versions of iOS older than 8 (PR)'

    Thursday, March 9, 2017 9:19 AM
  • User265422 posted

    Yes it is frustrating all these worries including performance with android, carouselview and more but I do not think either harass the team is beneficial. I think they are already putting pressure to themselves, especially if you want a quality result. I expect a lot like you from this update.

    @DavidOrtinau Have fun

    Thursday, March 9, 2017 2:21 PM
  • User53115 posted

    @RayTrask When Xamarin.Forms started, it featured Windows 8 Phone as a red-headed stepchild of a platform. UWP seems to be getting more support, but I wouldn't expect them to start targeting older, end-of-life platforms.

    Thursday, March 9, 2017 7:30 PM
  • User76916 posted

    @RayTrask - WPF on Xamarin Forms is in the works (as speculated from tweets by Miguel), hence Windows 7 desktop support might be possible. We might see a beta of it later this year.

    Also Windows 7 is 22.5% global, its less than 50% if you just look at Windows. Its slowly going down.

    Friday, March 10, 2017 8:33 AM
  • User139758 posted

    @AdamP where did he say something related to wpf on forms?

    Friday, March 10, 2017 9:44 PM
  • User76916 posted

    @"TobiasSchulz.9796" https://twitter.com/migueldeicaza/status/827220707465654272

    Saturday, March 11, 2017 12:12 AM
  • User76916 posted

    @"TobiasSchulz.9796" While I know its a bit of shameless plug, I do keep a track of these things and mention them in my monthly newsletter (http://us13.campaign-archive2.com/home/?u=9bc39dc111f08d2a130409419&id=68a7cafa60) You can look at past issues to what they are like. It has 450+ subscribers and I rarely get an unsubscribe, so I hope that means I am doing something right :)

    Monday, March 13, 2017 3:22 AM
  • User253073 posted

    Xamarin.Forms for macOS - Feature Xamarin.Forms is coming to macOS, joining iOS, Android, Windows, and Tizen as target platforms for Xamarin.Forms.

    like this!!!

    Monday, March 13, 2017 4:11 AM
  • User221964 posted

    Thanks @AdamP You're truly the Xamarin helper :)

    Monday, March 13, 2017 5:11 AM
  • User67129 posted

    Can we get an update to the roadmap? What things have been completed, which things have moved up or down the priority list? is everything still on track? Nearing the end of Q1 now

    Tuesday, March 21, 2017 2:37 PM
  • User176027 posted

    Now that almost every browser supports webassambly why not build something in XF and produce a web app!!!!

    Wednesday, March 22, 2017 12:36 PM
  • User250320 posted

    @GiorgosPapadakis Here here! And standardizes XF on UWP XAML too and compile to webassembly.

    Wednesday, March 22, 2017 12:43 PM
  • User250320 posted

    MS should just buy this: http://www.cshtml5.com/index.aspx

    And integrate it tightly with shared .netstandard libraries and android/ios/uwp. One place to rule them all.

    Wednesday, March 22, 2017 4:43 PM
  • User1869 posted

    Since the CSS / FB discussion is closed.

    Can someone please tell me what FlexBox gives us that we cant get from XAML with maybe just a few additions? I am a WPF dev as well and there really wasn't any layout we couldn't achievement in XAML with some code-behind.

    So why FlexBox?

    Sunday, March 26, 2017 1:46 AM
  • User258 posted

    @AdamHill

    Theres no good answer for that specific question.

    But if you ask "why was FlexBox added" I believe the answer is "because we had already made it, and we thought everyone would love it".

    Monday, March 27, 2017 7:57 AM
  • User130 posted

    @void I think @AdamHill's comment pretty clearly demonstrates it's not for "everyone". :)

    In the same way that the existing XAML layout system is powerful and productive for some, others find the way a FlexBox-like system flows and adapts makes more sense. You can review it on the dev branch now. We'll be putting out a preview package shortly and will encourage anyone interested to give it a look.

    Monday, March 27, 2017 9:54 PM
  • User6349 posted

    @"JamesHancock.1360" while I am a big fan of the CSHTML5/JSIL team what you are suggesting would actually be counterproductive to and for .NET. CSHTML5 and JSIL do not offer the capability of PCL or shared code between server and client. While this does make all the code more ".NET", you ultimately still end up with two incompatible codebases between client and server, and are left with the management/maintenance pains as such.

    Xamarin is really the best thing that has happened to .NET since Silverlight. They really know their stuff. I myself would prefer to see XF become more of a Noesis-based client model whereby you have the ultimate freedom to create your controls/UX the way you would like without being constrained by platform expectations/constraints. Also, having to create a custom renderer for each custom control for each and every platform seems like a significant hurdle and a lot unnecessary work, especially when such concern is easily handled by theming/templates. You know, much like how the web operates. :smile:

    Speaking of which @GiorgosPapadakis, Mono is currently being ported to WebAssembly so that will enable everything you know that runs on Mono to run on the Web. I myself am looking forward to checking out Noesis in full once this happens. ... or XF if it can adapt as well, accordingly :smile:.

    Wednesday, March 29, 2017 7:02 AM
  • User125713 posted

    @DavidOrtinau it's now April, what is the status of perf improvements on Android? I haven't seen any new check-ins in the android fast renderer branch for the last 4 weeks. When can we finally see some perf gains?

    Monday, April 3, 2017 5:23 AM
  • User311 posted

    @TonyD @DavidOrtinau It would be nice to have some performance benchmarks as well between versions.

    Cold startup time and layout performance. Is there a reference test app such as the gallery app that could be used as benchmark?

    Monday, April 3, 2017 6:43 AM
  • User65389 posted

    I have asked (regarding the performance) in the pre6 thread (in the hope for a feedback from some developers): https://forums.xamarin.com/discussion/87970/xamarin-forms-2-3-4-221-pre6#latest Unfortunately - no feedback (I don't hope, this is bad sign...?) I fully support the proposal of @rogihee: It really would be nice, if Xamarin would create a "performance benchmark app" (containing, specific pages with a lot of labels, a lot of images and a huge listview), would do tests with the benchmark app (at least with new "stable" versions) and let us know the results (startup time and specific pages)... So we all could compare the platforms (iOS vs Android vs Windows) but especially the (hopefully) approved performance for each platform This would especially make sense, as the performance further should be boosted for Android in the further releases this year. 2.3.4 is estimated for:

    2.3.4 - Est Q1 2017

    Q1 is over now... maybe an update of the roadmap would make sense...? Thanks

    Monday, April 3, 2017 10:47 AM
  • User130 posted

    @rogihee said: @TonyD @DavidOrtinau It would be nice to have some performance benchmarks as well between versions.

    Cold startup time and layout performance. Is there a reference test app such as the gallery app that could be used as benchmark?

    Good timing to discuss this! We are in the process of building out a gallery of common UIs specifically for measuring and tracking performance.

    Would anyone be open to contributing some of your common UI from existing apps?

    While we have a list and our own apps to guide what we will include in the tests, it would be most helpful to have a good selection from others in the community. I'm not looking for "best practices" or cleaned up code, but rather just what you are using. And just the layout, so hopefully that's an easy request rather than providing full production apps.

    If anyone would be up for that, I'll perhaps organize another thread to discuss how we do that. We'll also want to get our solution up on GitHub for everyone to contribute to. We have a foundation begun, but to make it easy for everyone to contribute UIs we need to do more and I think seeing some of the UIs we will be testing would be very helpful.

    Re: fast renderers, we have been reviewing and testing them. They will soon be in the nightly builds (I believe there's a merge PR in the works or awaiting review) and then our next pre-release. We have also scheduled to work on the other renderers, and then iOS. The commits on that branch aren't the whole story.

    We have had some design discussions the past few weeks about Android performance specifically and are exploring additional areas of improvement.

    Expect some announcements on release status and more this week.

    Monday, April 3, 2017 1:53 PM
  • User311 posted

    @DavidOrtinau great to hear! I have an app with a quite complex dashboard layout, with slightly overlapping gauges and layering. It's performance is not that good at the moment, but at least it's working on all resolutions :-) on iOS and Android. Might be a good candidate to contribute. I have ideas to improve it of course, but perhaps it's nice to have an awful page and "optimized" page, so we can all learn from that.

    Monday, April 3, 2017 3:22 PM
  • User65389 posted

    @DavidOrtinau Thanks for your feedback... this sounds good...

    Monday, April 3, 2017 3:36 PM
  • User130 posted

    @rogihee exactly, we want "real world". I also have the notion of building a "most performant" alternative for each that can start to serve as educational references.

    Monday, April 3, 2017 7:37 PM
  • User51906 posted

    @DavidOrtinau I would also have a rather complex dashboard with Grids, Stacklayout, Buttons and a ListView. The performance is ok right now, but I think it could help you

    Tuesday, April 4, 2017 5:10 AM
  • User242131 posted

    Glad to hear drag and drop may be added to the roadmap. Question: the Slider is an example of drag and drop, yes? It must be processing grab, drag and drop events, yes? Although its bounds are controlled.

    A comment: UWP's interface for managing drag and drop events are clean, yes?

    Tuesday, April 4, 2017 6:27 PM
  • User242131 posted

    Slider is not an example of drag and drop. It resolves to a control.

    Wednesday, April 5, 2017 2:07 AM
  • User141987 posted

    Can't wait for Xamarin.Forms Embedding!!!

    Thursday, April 6, 2017 1:51 PM
  • User251799 posted

    @DavidOrtinau said: Good timing to discuss this! We are in the process of building out a gallery of common UIs specifically for measuring and tracking performance.

    I have one: I recently posted something about dog fooding on a bug report of mine. I would love you guys to just create a simple chat interface that actually does work like one would supposed to: Proper scrollable list rendering, a text input box on the bottom that works with text input, and a layout that works for both text input and viewing. This has a lot of common use cases, and it's so trivial that I used it as an interview exercise for UI devs in my team, but it literally took me weeks to get it somewhat working on XF Android/iOS, and it still feels clunky.

    Friday, April 7, 2017 4:58 PM
  • User110999 posted

    @DavidOrtinau and Xamarin technical team, In order to dramatically improve app startup performance on Android,

    Why not ask, formally, Google to ship Mono and Xamarin.Android assemblies with Android itself? As you are part of Microsoft right now, probably you have much better contractual power to persuade Google implementing this functionality

    This will dramatically improve any app startup due to assembly prefetch at device boot.

    This will also make it possible for developers to code Instant Apps with Xamarin

    Sunday, April 9, 2017 9:27 AM
  • User76049 posted

    @DavidOrtinau

    Any ideas on when Forms will allow XamlC and embedding native controls in XAML?

    It's a feature I'd like but disabling XamlC is too big a performance hit to consider for production apps.....and I don't use shared projects :smile:

    Monday, April 10, 2017 11:13 AM
  • User125713 posted

    @DavidOrtinau said: Expect some announcements on release status and more this week.

    Can we get those now? What's the status of Android fast renderers and other performance fixes?

    Monday, April 10, 2017 8:32 PM
  • User311 posted

    @TonyD the first round of fastrenderers is now in the repo https://github.com/xamarin/Xamarin.Forms/pull/845

    Tuesday, April 11, 2017 6:26 AM
  • User113114 posted

    A bird is telling me the nightly build hasnt built the past week. @DavidOrtinau

    Tuesday, April 11, 2017 2:23 PM
  • User43 posted

    @rogihee: We also discuss fast renderers at the end of the last Xamarin Podcast for those interested (what they are, what sort of performance boost they give, etc.)

    Tuesday, April 11, 2017 2:26 PM
  • User139040 posted

    @DavidOrtinau @PierceBoggan What is the correct way to "turn on" fast renderers for testing purposes? I have the latest compiled and in use and wanted to do some speed comparisons. Are they automagically or do we have to force them some way?

    Thursday, April 13, 2017 12:40 PM
  • User130 posted

    @BradChase.2654 said: @DavidOrtinau @PierceBoggan What is the correct way to "turn on" fast renderers for testing purposes? I have the latest compiled and in use and wanted to do some speed comparisons. Are they automagically or do we have to force them some way?

    They are on be default in the pre-release and nightly. Nightly is a debug build. Pre is a release build.

    Please report your speed comparison findings, and detail your test scenario and hardware.

    Thursday, April 13, 2017 1:16 PM
  • User130 posted

    @BjornB said: A bird is telling me the nightly build hasnt built the past week. @DavidOrtinau

    We are aware. It will only build when there are commits and when it passes all tests. We have a failing test that has been blocking it. It was fixed late last night and awaiting a review today so master will be green once more.

    Thursday, April 13, 2017 1:20 PM
  • User130 posted

    @NMackay said: @DavidOrtinau

    Any ideas on when Forms will allow XamlC and embedding native controls in XAML?

    It's a feature I'd like but disabling XamlC is too big a performance hit to consider for production apps.....and I don't use shared projects :smile:

    It's still on the roadmap for Q2. I just had a discussion about it yesterday in fact. We have a some heavy lifting to do before it'll be "road worthy" and in a pre-release. As it seems with most things performance related, there are very few easy wins.

    Forms Embedding in Android, more work on Fast Renderers, Layout Compression, and additional Startup Time Improvements are presently ahead of it.

    Thursday, April 13, 2017 1:32 PM
  • User139040 posted

    @DavidOrtinau Thanks for the info there. We are running a custom build currently so we are in release anyways. In terms of custom renderers, do we need to inherit those from the fast renderers or change those at all?

    edit: It appears you do. I took out the label renderer just to see how the fast renderer performed and it bombed right out with a generic exception and no stacktrace. It will take some time to go through it all at a later point.

    Thursday, April 13, 2017 2:53 PM
  • User317996 posted

    probably it's much better to put in use some VOTE-FOR-IMPROVEMENT forum + Trello.com roadmap just the way Unreal 4 Engine put it in use. check it up : https://trello.com/b/gHooNW9I/ue4-roadmap

    Wednesday, April 19, 2017 2:15 PM
  • User181025 posted

    @DavidOrtinau

    What do you have in place to ensure Android performance doesn't get worse as new code is checked in? Do you have any performance benchmarks that you run that new PRs must meet before they are eligible for merging? I just want to make sure any performance improvements are not voided over time by new features / bug fixes.

    Also, have you guys consulted Google at all in the past regarding performance? Maybe you could hire a few of their consultants to get advice on what to improve and how. I think Android design is crap and it takes a lot to understand how different pieces are moving. I'd assume they have better knowledge of their system than any third-party can.

    Lastly, I'd like to see your input on @LucaPisano's comments. :)

    Thursday, May 11, 2017 5:37 PM
  • User139040 posted

    @AdrianKnight Adrian, can you elaborate for me a bit on the crap side? Do you mean Xamarin.Form's implementation of the Android layout or Google's core Android layout design?

    I ask because I think the large part of the android speed issues is on Xamarin's side. I see alot of areas on the Forms layout code which can be improved. I have been working on the GridCalc and rewrote it where some of our views side by side have a 3 second load increase (EDIT: Read as 3 seconds faster load times). I need to nail down what should be expected and what should not happen before I can release it but I definitely plan on it. Currently everything renders correctly with Xamarin's GridCalc and my GridCalc but we use very exacting XAML where other developers might not have and will see issues in their views that need to be corrected.

    That said, I think there are other problematic areas that are causing the measure/arrange passes to be called too often or sometimes not called when they should. One big offender I found was when leaving an Android app and coming back, somethings that were not visible then turned to visible dont render correctly. I think a small overhaul of the core layout controls will give Android its much needed boost as well as the other OSs. Thoughts?

    Thursday, May 11, 2017 10:45 PM
  • User181025 posted

    @"BradChase.2654" Brad, what I meant was Android development is too complex. There is a lot of backwards compatibility stuff, support libraries, xml files, outdated and/or confusing documentation, difficult process management, poor API design, etc.

    I see alot of areas on the Forms layout code which can be improved.

    You're right, and Xamarin has a roadmap to speed things up. While I believe we should expect to see faster load times in the near future, part of me believes the complexity of Android will require real expertise if Xamarin wants to deliver an optimum product.

    Friday, May 12, 2017 12:05 AM
  • User57869 posted

    When is XF 3.0 expected to be launched? Do you already have more info about it than you mentioned at Build?

    Tuesday, May 16, 2017 2:43 PM
  • User324191 posted

    Please. Visual editor for XAML like to CorelDraw "Designer along with an interactive node based editor"

    This is something that has been asking for a long time, please, it's past the time XAML has a complete visual editor, a decent Designer along with an interactive node based editor for animation, events and custom controls creation and realtime test and prototype

    Tuesday, May 16, 2017 9:48 PM
  • User324191 posted

    I think it would be great for developers if Xamarin adds a unified approach to multi-platform development, that is. "Write once and compile for various platforms without any code change", approach that Embarcadeiro follows, unfortunate to Embarcadeiro is sinning in several aspects; Such as the use of outdated language like Objective Pascal (Delphi) and C ++, not to mention that Embarcadeiro does not have a good IDE and does not have an XML-based language for defining the graphical interface. If Embarcadero places a language such as C # or Java in the Pipeline and an XML-based language for defining the graphical interface, Embarcadero would be the best alternative for multi-platform development

    Tuesday, May 16, 2017 10:01 PM
  • User130 posted

    @AdrianKnight said: @DavidOrtinau

    What do you have in place to ensure Android performance doesn't get worse as new code is checked in? Do you have any performance benchmarks that you run that new PRs must meet before they are eligible for merging? I just want to make sure any performance improvements are not voided over time by new features / bug fixes.

    We have begun working on a suite of app benchmark tests to compare version to version, report on that, and eventually be able to run this based on particular commits integrated with our CI. I think it's getting close to something we can use.

    Also, have you guys consulted Google at all in the past regarding performance? Maybe you could hire a few of their consultants to get advice on what to improve and how. I think Android design is crap and it takes a lot to understand how different pieces are moving. I'd assume they have better knowledge of their system than any third-party can.

    I don't have direct knowledge of that history. We have plenty of things we do understand and we are working to solve those. And we have had plenty of discussions with our Android team, some of which has led to things on our roadmap.

    Lastly, I'd like to see your input on @LucaPisano's comments. :)

    Which? Shipping assemblies?

    Wednesday, May 17, 2017 2:29 AM
  • User130 posted

    @MichaelRumpler said: When is XF 3.0 expected to be launched? Do you already have more info about it than you mentioned at Build?

    Now that Build is done, I'm going into planning with the team to revise the roadmap and set some expectations on delivery time frames.

    Wednesday, May 17, 2017 2:35 AM
  • User130 posted

    @IsaqueNeves said: Please. Visual editor for XAML like to CorelDraw "Designer along with an interactive node based editor"

    This is something that has been asking for a long time, please, it's past the time XAML has a complete visual editor, a decent Designer along with an interactive node based editor for animation, events and custom controls creation and realtime test and prototype

    Thanks for the suggestion. I suspect you're not alone in that request.

    I wasn't aware CorelDraw had an interactive editor. I'll have to explore that.

    Wednesday, May 17, 2017 2:37 AM
  • User251799 posted

    I can only iterate: Please stop adding features, and focus on getting the platform right with some proper QA. Issues like https://bugzilla.xamarin.com/show_bug.cgi?id=56240 (which basically kills Android development for everybody who upgrades Xamarin or VS2017) are just a no-go, and there's a pattern here. In order to avoid stuff like that, I wished there was better QC and more dog-fooding on your end.

    Of course it might hurt to wait for some features, but then, if the foundation isn't working, there's no point in having those, too. I'm a prototypical .NET fanboy, but to be honest, I find myself wishfully looking at other tech just to get away from days of hunting bugs that aren't my own.

    Wednesday, May 17, 2017 7:32 AM
  • User3516 posted

    I think one of the problems is, that major versions are rushed because they need to be ready for the next Build or Evolve or whatever big conference is next.

    Wednesday, May 17, 2017 8:07 AM
  • User258 posted

    @DirkWilhelm said: I think one of the problems is, that major versions are rushed because they need to be ready for the next Build or Evolve or whatever big conference is next.

    +1

    Wednesday, May 17, 2017 8:36 AM
  • User76049 posted

    @DirkWilhelm said: I think one of the problems is, that major versions are rushed because they need to be ready for the next Build or Evolve or whatever big conference is next.

    +1

    Wednesday, May 17, 2017 9:06 AM
  • User181025 posted

    @DavidOrtinau

    Which? Shipping assemblies?

    Yep.

    Why not ask, formally, Google to ship Mono and Xamarin.Android assemblies with Android itself? As you are part of Microsoft right now, probably you have much better contractual power to persuade Google implementing this functionality

    Is this doable? Since thousands of devs use Mono and Google would be interested in making it easier for devs to develop for their platform, I'd assume this is a reasonable offer to make.

    Wednesday, May 17, 2017 2:09 PM
  • User3516 posted

    @AdrianKnight said: @DavidOrtinau

    Which? Shipping assemblies?

    Yep.

    Why not ask, formally, Google to ship Mono and Xamarin.Android assemblies with Android itself? As you are part of Microsoft right now, probably you have much better contractual power to persuade Google implementing this functionality

    Is this doable? Since thousands of devs use Mono and Google would be interested in making it easier for devs to develop for their platform, I'd assume this is a reasonable offer to make.

    I see a problem with this.

    Lets say Google can be pursuaded to ship the assemblies in one of their next andoid version. At first they would be available on the newest Google Hardware that ship with the newest android Version.

    Now other brands are often not that fast to deliver new android versions or don't provide older hardware with an update.

    How will updates to the assamblies be handled? Wait till the next android version is released? And then again wait till the other brands update their versions?

    Wednesday, May 17, 2017 2:54 PM
  • User130 posted

    @DirkWilhelm said: I think one of the problems is, that major versions are rushed because they need to be ready for the next Build or Evolve or whatever big conference is next.

    Agree. We didn't want to rush, which is exactly why we announced the vision for Xamarin.Forms 3.0 at Build 2017 instead of pushing a release package.

    Thursday, May 18, 2017 3:33 PM
  • User130 posted

    @PhilippSumi said: I can only iterate: Please stop adding features, and focus on getting the platform right with some proper QA. Issues like https://bugzilla.xamarin.com/show_bug.cgi?id=56240 (which basically kills Android development for everybody who upgrades Xamarin or VS2017) are just a no-go, and there's a pattern here. In order to avoid stuff like that, I wished there was better QC and more dog-fooding on your end.

    Of course it might hurt to wait for some features, but then, if the foundation isn't working, there's no point in having those, too. I'm a prototypical .NET fanboy, but to be honest, I find myself wishfully looking at other tech just to get away from days of hunting bugs that aren't my own.

    I hear you. In terms of the Xamarin.Forms team, the majority of our focus is on quality and performance. I'm working on improving our QA, as well as our bugzilla strategy. We have new CI features in the works specifically to track and alert performance.

    The Android/Mono/Runtime team(s) are addressing that perf bug, and it should not have gotten through release. The Xamarin.Forms team cannot do anything about it at this time, other than provide repro projects and support them.

    We plan to continue adding features, but some of these features or enhancements are improvements of areas contributing to bugs or performance issues. As I look over the list (I'm updating this roadmap today) it appears more than half are for performance.

    Thursday, May 18, 2017 3:43 PM
  • User130 posted

    @AdrianKnight said: @DavidOrtinau Is this doable? Since thousands of devs use Mono and Google would be interested in making it easier for devs to develop for their platform, I'd assume this is a reasonable offer to make.

    As I recall Adobe got them to ship their AIR runtime in the early days. I'd be shocked if it hadn't been discussed already, but I'm not afraid to ask.

    Thursday, May 18, 2017 3:48 PM
  • User324191 posted

    @DavidOrtinau

    I think you hear a mistake, English is not my native language, so please forgive me if I made myself understand that CorelDraw has an interactive editor on, what I meant is that in addition to a good Designer tool for XAML, it should Autodesk 3ds Max Max Creation Graph (MCG) for creating custom controls, prototyping, animation definition, events, and so on.

    Thursday, May 18, 2017 8:31 PM
  • User55911 posted

    I love the direct conversion of Xamarin Forms pages to Native however what I would like to see is if we can tag certain views in Xamarin Forms so that when we convert there is a way to get the native control from the converted view (without looking for the type etc). Example : - I have a xamarin forms page with Button X - I convert the page to xamarin native iOS and Android - Now usually I wouldn't be able to grab the X button unless I look through the views for a certain property etc - With the new implementation I would be able to have a way to grab the Button based on an simple method - UIButton buttonX = GetXamarinFormsNativeControl(ViewControllerConvertedFromXamarinFormsPage, "someTagSetInXaml") - now I can adjust the buttonX control natively to my likings.

    Friday, May 19, 2017 6:22 PM
  • User320792 posted

    @DirkWilhelm said:

    How will updates to the assamblies be handled? Wait till the next android version is released? And then again wait till the other brands update their versions?

    As examples: Google Play Services and OpenCV Manager

    In related news from Google I/O: Support Library v26 adds Font Provider support, which utilizes Google Play Services to cache fonts across apps. (EmojiCompat also requires Play services, since they're fonts as well.)

    As a note: Google Play Services typically just tells the user to update to the latest version, if an update is required. I don't know how it handles compatibility with older apps.

    OpenCV Manager makes it clear to the user which versions of OpenCV are loaded, and apps implementing OpenCV requests a specific version from the Manager.

    As a result, I don't think it'd be completely unheard of for a common "Xamarin services" APK that handles management of Xamarin assembly versions required by apps that you use.

    Friday, May 19, 2017 11:29 PM
  • User230357 posted

    @DavidOrtinau said: This roadmap outlines our anticipated feature releases.

    Great selection of upgrades. Thank you!

    Xamarin.Forms for macOS Xamarin.Forms for GTK# Xamarin.Forms for WPF

    Will be tremendous if this is a success. Xamarin.Forms will have extremely broad coverage.

    Success will depend on support from 3rd party components. Making it easier to support the wide range of X.F platforms, or rewarding components that do with more visibility would help. Fixing https://components.xamarin.com/ would be a good start as viewing components by OS tags is limited to very basic tags and doesn't actually work.

    Saturday, May 20, 2017 1:33 PM
  • User320792 posted

    @CharlesRoddie said:

    @DavidOrtinau said: Xamarin.Forms for macOS Xamarin.Forms for GTK# Xamarin.Forms for WPF

    Will be tremendous if this is a success. Xamarin.Forms will have extremely broad coverage.

    Success will depend on support from 3rd party components. Making it easier to support the wide range of X.F platforms, or rewarding components that do with more visibility would help. Fixing https://components.xamarin.com/ would be a good start as viewing components by OS tags is limited to very basic tags and doesn't actually work.

    I agree that there needs to be a better way to find 3rd party components. Preferably with a way to specify open-source (with links to Github) or license type.

    Whenever I've gone to the Xamarin Components site, I've always left dissatisfied and ended up Googling what I wanted.

    As a developer, I can certainly understand why Microsoft might want to promote (or allow developers to pay them to promote) paid components... But it often seems that this leads to a bunch of components unrelated to what I'm looking for being suggested instead.

    As an example of a components discovery site done well, there's Google's https://www.webcomponents.org/

    Granted, Google benefits from having great search algorithms... Maybe the Xamarin team could get some help from the Bing team here?

    Saturday, May 20, 2017 8:29 PM
  • User320792 posted

    In addition to improved discovery of 3rd party Xamarin.Forms components, I think it might be nice for the Forms team to re-evaluate how certain cross-platform components work.

    e.g. The TabbedPage: Google's Material Design spec (which has been promoted by @JamesMontemagno himself) now specifies Bottom Navigation which is analogous to Apple's UITabBarController.

    Perhaps add a TabPosition property that allows the user to specify Bottom or Top with the default behavior being the current.

    The Top tabs could be like the existing Android and WP implementation, with iOS possibly using a UISegmentedControl added to the Navigation Bar.

    I certainly respect that the original goal was to prefer a platform's behavior, in order to make the user of that platform feel more comfortable... But I'll note that the MasterDetailPage is kind of foreign to native iOS.

    In native iOS, this would be a UISplitViewController with a UITableViewController as the Master, rather than a slide-out drawer. To this day, Apple hasn't added a Navigation Drawer (and to the best of my knowledge as an avid iOS user, they haven't utilized any such control in their standard apps.)

    The Navigation Drawer only really rose to use in iOS as a result of people wanting cross-platform apps to behave more similarly.

    For that matter, I actually think something more like a UISplitViewController has value as a Page component.

    Let's take a "file manager" or email setup as an example: You click on the file or email that you want to view and (on small phones) transition to the detail view. Having a "slide-out" Navigation Drawer doesn't make much sense in that use case.

    Saturday, May 20, 2017 8:51 PM
  • User130 posted

    @Qwin said: I love the direct conversion of Xamarin Forms pages to Native however what I would like to see is if we can tag certain views in Xamarin Forms so that when we convert there is a way to get the native control from the converted view (without looking for the type etc). Example : - I have a xamarin forms page with Button X - I convert the page to xamarin native iOS and Android - Now usually I wouldn't be able to grab the X button unless I look through the views for a certain property etc - With the new implementation I would be able to have a way to grab the Button based on an simple method - UIButton buttonX = GetXamarinFormsNativeControl(ViewControllerConvertedFromXamarinFormsPage, "someTagSetInXaml") - now I can adjust the buttonX control natively to my likings.

    I believe you can just use Platform.GetRenderer(theVisualElementYouWant). To get it without going through the children of your page, you could expose it as a public property or add a GetMyButton() method and use the x:Name.

    Monday, May 22, 2017 4:33 PM
  • User55911 posted

    @DavidOrtinau said:

    @Qwin said: I love the direct conversion of Xamarin Forms pages to Native however what I would like to see is if we can tag certain views in Xamarin Forms so that when we convert there is a way to get the native control from the converted view (without looking for the type etc). Example : - I have a xamarin forms page with Button X - I convert the page to xamarin native iOS and Android - Now usually I wouldn't be able to grab the X button unless I look through the views for a certain property etc - With the new implementation I would be able to have a way to grab the Button based on an simple method - UIButton buttonX = GetXamarinFormsNativeControl(ViewControllerConvertedFromXamarinFormsPage, "someTagSetInXaml") - now I can adjust the buttonX control natively to my likings.

    I believe you can just use Platform.GetRenderer(theVisualElementYouWant). To get it without going through the children of your page, you could expose it as a public property or add a GetMyButton() method and use the x:Name.

    That is true that we could use Platform.GetRenderer, however I noticed a lot of problems when using it, these might be just bugs hopefully fixed in the future. (problems like rendering the native control, some things go missing or not converted correctly)

    Also I wanted to mention another problem I always get with Renderers is their extensibility. Let's say I wanted to add different libraries to the Listview (ListviewRenderer). I would need to change immense a lot of code to support for instance swiping features which are available by third party libraries. (I tried it, and got even into issues of memory management, caching and other stuff which made it a separate project by itself. Definitely the handling of recycling without causing memory leaks was almost impossible). So I hope renderers get simplified and easier to manage in the future of Xamarin Forms 3.0.

    Monday, May 22, 2017 6:29 PM
  • User130 posted

    @ChrisBoyd @CharlesRoddie great feedback, thank you. Discoverability between NuGet and the Component Store, and the overlap is something the component team has discussed needing and deserving improvement. I'll make sure to pass this along.

    We are evaluating changing platform design, Bottom Navigation being a great example. And we'll be improving that. That's great feedback, thanks!

    Tuesday, May 23, 2017 2:33 PM
  • User66766 posted

    @DavidOrtinau I proposed Bottom Nav for android in the Evolution a while back. I would love to see this added as this is now the defacto material design for tabbed navigation

    Tuesday, May 23, 2017 2:38 PM
  • User130 posted

    @Qwin please file some reports on specific renderers that have issue with Platform.GetRenderer. I'm not aware of any, so that would be very helpful.

    Agreed, renderer extensibility is indeed an improvement we are making in 3.0, and ListView and cells is a big one.

    Re: swipe cells, I just saw some work from @MatthewRobbins that did this and looked great.

    Tuesday, May 23, 2017 2:39 PM
  • User52264 posted

    Xamarin.Forms for GTK#

    thats great!

    would be nice to have a link to the dev-sources, maybe to contribute some stuff!

    Tuesday, May 23, 2017 5:49 PM
  • User34778 posted

    @DavidOrtinau, @Qwin Regarding swipeable cells; I'm planning on doing a blog post and open sourced repo to show how we did it when I get the time.

    Tuesday, May 23, 2017 10:11 PM
  • User181025 posted

    @DavidOrtinau

    When should we expect PR 853 to be merged into master? I need to start developing a new app that relies on this control. Instead of waiting till Q3, I'd like to work off of nightly builds or XF fork till Q3, but it'd be nice to see this in master soon.

    Alternatively, I might grab the Nuget / plugin, so I'm debating if it's worth the wait. Please advise. :)

    Wednesday, May 24, 2017 3:33 PM
  • User239635 posted

    Is it time to do start doing some regression testing on Xamarin releases? every time I update there is a surprise - the most recent ones were "build failed dll used by another process" and ios breakpoints aren't hit.

    should there be some idea of a minimum software quality that's acceptable for release? or is it just whatever goes is ok? I don't get it.

    to be honest Xamarin spoils the perception of quality of Visual Studio environment. takes it from 10-star to 1-star. Does anyone at Microsoft care about quality of VS as as development environment?

    Wednesday, May 24, 2017 7:06 PM
  • User18728 posted

    I'm seeing the iOS breakpoint issue when debugging on device. Simulator seems to work OK though. But the dll in use issue is getting really annoying.

    Wednesday, May 24, 2017 7:12 PM
  • User139040 posted

    Android is broken as well fyi. I think two things need to change. One, there really doesnt seem to be much internal testing what so ever when it comes to releases(alpha or otherwise). It appears the greatest testing asset they have currently is us. The second part is, because of the current issues with releases and cycles, it might be a good idea on the newly released channel selector for VS2017 to update the extension and allow us to pick a version to use instead of only 3 channels.

    And dont stop there. Allow us to select which version we want with which OS. Currently there are issues with Droid that are find on iOS but then another version has one where something is fine on iOS but broken on Droid. It would be nice to just pick which version we can use best with each OS.

    EDIT: To add, I hope I am not being too harsh. I know these quick non tested releases tend to happen more often than not during conference time unfortunately :(. It isnt always this bad guys...

    Wednesday, May 24, 2017 8:13 PM
  • User212120 posted

    I am very excited about the g18n and RTL support, as it's the only thing holding me off from using XF right now. Well done guys!

    Friday, May 26, 2017 5:27 PM
  • User315050 posted

    I'm well aware of this issue, hence why we're stuck on cycle8 but at least we can debug.

    Saturday, May 27, 2017 7:45 AM
  • User248484 posted

    WOW that's indeed a great list. I'm especially turned on by XAML Standard.

    Besides, I'm waiting for Xamarin to start supplying more controls, even non-native, maybe in a different namespace. ItemsControl, RadioButton, CheckBox, DateTimePicker etc. With the lack of ItemsControl counterpart, you feel like crippled. As a mainly WPF and former Silverlight dev concentrating in LoB apps, these controls are very demanding and are total deal-changers.

    Anyway thanks for all your efforts guys, since MS acquired Xamarin it's definitely on the right path again!

    Sunday, May 28, 2017 8:23 PM
  • User263 posted

    @DavidOrtinau Thanks for the updates. Would it be possible to start a thread to discuss the new VisualStateManager on the roadmap? Keen to understand how this will work and what it will do, as we have built our own and interested to see what the migration path will be.

    Thanks!

    Thursday, June 1, 2017 11:01 AM
  • User4513 posted

    When are we going to see a update to CarouselView? It's a pretty embarrasing situation. Xamarin should really decide if they are going to support it and fix some of the issues, or depreciate it completely and we'll use 3rd party solutions

    Wednesday, June 7, 2017 12:01 AM
  • User299480 posted

    @DavidAllen I think the XF team is still busy implementing features no one asked for. Maybe once they're done with the 3.0 gimmicks they can focus on performance and the existing broken features again.

    Wednesday, June 7, 2017 6:00 AM
  • User171749 posted

    @DavidAllen said: When are we going to see a update to CarouselView? It's a pretty embarrasing situation. Xamarin should really decide if they are going to support it and fix some of the issues, or depreciate it completely and we'll use 3rd party solutions

    There are updates on the CarouselView if you follow the GitHub... https://github.com/xamarin/Xamarin.Forms/pull/853

    Wednesday, June 7, 2017 7:38 AM
  • User88552 posted

    Xaamrin.Forms is still buggy

    Wednesday, June 7, 2017 8:23 AM
  • User306807 posted

    @DavidAllen, as Sean mentioned it its already decided what's gonna happen.

    https://github.com/alexrainman/CarouselView That's the controll which will be merged into XF and its recommended to use it until its part of XF...hopefully in Q3. It works pretty well, especially compared to XF Carousel View.

    Wednesday, June 7, 2017 8:38 AM
  • User240159 posted

    I've just came after a few months to Xamarin Forms, and I though, that it would be more mature, then before... but it isn't.

    God f.. damn it. Everything is broken - building app requires some stupid workarounds - https://acaliaro.wordpress.com/2017/05/29/the-xamlctask-task-failed-unexpectedly/

    Newest XF nugets has broken DataTriggers - https://bugzilla.xamarin.com/show_bug.cgi?id=56515 Everything is messy, building and signing apps required stupid workaround!

    And if your project has multiple 3rd party components - like Telerik, or any other plugins, you are more and more in black hole of "it's not compiling at all, even your *.CS code is fine".

    Wednesday, June 7, 2017 1:13 PM
  • User4513 posted

    @seanyda & @wend0rlin, thanks for the information. I had assumed that the Xamarin Carousel control was the one they would be supporting. WIll migrate over

    Wednesday, June 7, 2017 3:26 PM
  • User275358 posted

    @JLews said: @DavidAllen I think the XF team is still busy implementing features no one asked for. Maybe once they're done with the 3.0 gimmicks they can focus on performance and the existing broken features again.

    My thoughts too.

    CC'ing Miguel and Nat: @MigueldeIcaza @NatFriedman

    I'm sorry for having to say this but I've rarely seen a project so badly managed as Xamarin Forms.

    Xamarin is announcing with fanfare on their blog different features in Xamarin Forms when in reality, there are still issues with common features or some are still missing.

    iOS and Android support is still buggy and performance is pretty bad with even basic pages. It's not hard to see a lag when navigating between simple pages. I understand Xamarin Forms will never have same speed as native, but looking at the code and architecture of the Xamarin Forms, it's obvious there is much room for improvement.

    Despite the fact I still don't understand why Microsoft would pay many millions of $ in salaries for the implementation and support of a mobile development platform for Android and iOS, I thought after Xamarin joined Microsoft, Xamarin Forms development progress will "explode", given than there are extraordinary people at Microsoft who designed and implemented the XAML frameworks WPF, Silverlight, especially WindowsPhone, UWP, people which can help or at least share critical knowledge to Xamarin related to architecture and performance.

    Xamarin encourages people to contribute, but there are important contributions in PRs which haven't been reviewed for weeks \ months: * Swipe Gesture (how can you not have this?) no response since April 24 https://github.com/xamarin/Xamarin.Forms/pull/880 * Merged Dictionaries no response since May 8: https://github.com/xamarin/Xamarin.Forms/pull/869

    These are just a few...

    I'm NOT pointing fingers at the Xamarin Forms team members, they are not to blame! There's so much things to do and team is small.

    It makes no sense. Xamarin Forms is announcing with fanfare Xamarin Forms 3.0 adopting XAML Standard (which will require a lot of work), support for Samsung's Tinzen, but in the same time you don't have time to really nail the support for at least iOS and Android.

    Xamarin also announced in a blog post support for WPF, but "forgot" to mention that it's actually a PR by someone outside the team: https://github.com/xamarin/Xamarin.Forms/pull/895 I personally don't appreciate these marketing attempts at all, Xamarin is shooting themselves in the foot.

    Also, what is "CSS-Like Styling" in the roadmap. Who asked for that?

    How are you going to actually deliver all these promised features in a timely manner? Are they going to be just some half baked implementations like other features? When is XAML Preview for Xamarin Forms going to actually work 100%?

    With the slow progress, by the time Xamarin Forms is really working, JavaScript (or something else) will look and work like C# and web development will have almost all the capability of native, including access to camera and sensors. Some of these are already happening.

    I'm sorry but Xamarin Forms looks to me mostly like a marketing gimmick used by Microsoft.

    Thursday, June 8, 2017 8:56 AM
  • User2267 posted

    It's a shame that Forms is giving Xamarin a bloody nose. I've been using Xamarin.iOS and Xamarin.Android for years and they have benefitted me tremendously. They are both rock solid technologies. With good design you can achieve high code reuse between platforms. That said, I will give XF Embedded a spin. That's a feature I will welcome. I suspect a lot of developers who have not been brave enough to fully adopt Forms are looking forward to the ability to integrate Forms in such a manner. That particular part of XF 3.0 is going to be well received. Not by those who jumped fully into Forms but by those who didn't but would like to leverage just parts of XF. If it turns out that even that is too buggy I'll just go back to doing what I've been doing....which works perfectly. Being able to use the same UI code will be nice but I have to keep things in perspective. A recent project had me adding several non-trivial dialogs to one of my enterprise apps. It only took me 2 days to fully duplicate the dialogs in iOS on Android. Granted, I don't have a desktop version of the app too.

    Thursday, June 8, 2017 11:15 AM
  • User65389 posted

    Although, I waste my time one more time to write here (it’s at least good for my nerves and my soul)...

    @fabior is absolutely right...

    I have posted the thread below in May 2015

    https://forums.xamarin.com/discussion/41588/how-to-make-forms-stable/p1

    It was interesting for many, many users (see thread) and contains many useful proposals... Instead of take the proposal serious and improve the processes, Xamarin has “deactivated” the thread by prevent it from pop, if a new posting was added... You can copy-paste the information’s in the thread from May 2015 to May 2017...

    I further had direct contact to some Xamarin employees (to .forms and to the VS-integration) in the history and have wasted more time by describe the problems in detail and further describe proposals in detail... Nothing has changed...

    The base still don’t work (debugger often don’t work, variables are not viewable in debugger, the whole development environment works not stable and is very slow) And... this is daily base work of every developer and cost ”count of developer” x “every day wasted time”

    For Xamarin, it’s further self-evident, that: - the developers has to find out new bug’s and not solved solved bugs after every update - the developers have to create a “minimum sample project” for almost any bug, as Xamarin don’t want to invest the time to find out the reason / cause to the bug according the posted bugzilla description entry to the bug

    Every update (.forms but also new versions of VS integration SW, VS versions, and also all related SW like MAC, OS, Xcode and so on) has to be feared, as the chance is greater than 50% that the app will not be usable after the update and every developer has to invest hours if not days, only to be able to compile and user the app again after the update...

    How should we be able to work productive in such an environment...?

    Instead of make the base (.forms itself and the related software) rock-solid, nothing in the processes is changed (copy-paste from 2015), but new, not needed and not working “features” are added so that .forms becomes more and more instable... Periodically (once again in this thread) , Xamarin say’s, that the bug solving and stabilization hast the highest priority... I... don’t... can... see... any sign..

    So the proposals in the thread of 2015 still are valid in 2017! Please hold your promises: - first make .forms (and the whole environment) stable and really test new versions, before you use the word “stable” in the new version and let us do our daily work on a productive way - then, add missing new functions features, that every developer needs (like, e.g. such trivial things as set a font size to a piker without the need to create a “custom render”, or add a usable popup control that can be used without the need to search and add some other package to be able to show a popup) - then add features and gimmicks that only and "handful" developer

    Thursday, June 8, 2017 11:38 AM
  • User275358 posted

    Make no mistakes, Xamarin Forms is a great technology! However, I think due to poor management, because team remained too small, it's been progressing slow, too slow.

    It's a bit irresponsible from Xamarin to engage and promise to developers so many Xamarin Forms features at once, not being able to make at least iOS and Android(which is what mobile is today) run as good and as fast as possible.

    Xamarin should stop everything and have a simple roadmap for 2017:

    1. Refactor \ rewrite Xamarin Forms with an architecture which delivers as much performance as possible. Since Xamarin is part of Microsoft, I was expecting Microsoft's XAML platform (especially Windows Phone since it runs on mobile) architects to help with this.

    2. Stabilize as much as possible the implementation for iOS and Android.

    3. Add as many features related to controls and XAML as possible. For this, listen to developers. Don't promise features like "CSS-Like Styling" which honestly do not make much sense. How did that go into the roadmap?

    4. In parallel, at least make Xamarin Forms XAML Preview work as good as possible.

    I've seen tweets from Miguel this week about hiring new people to join Xamarin Forms team. Which is good news. I hope at least 5-7 positions are available. But this is unrelated to starting and promising too many features at once, instead of focusing on iOS and Android.

    Thursday, June 8, 2017 12:21 PM
  • User258 posted

    I'm very fond of Xamarin and Forms in particular. You can be very productive but I think that there will always be a certain amount of pain that you as a developer will need to live with.

    The task that Microsoft is undertaking is a huge one. They have to abstract away the differences of multiple platforms while ensuring you can get to the metal. And they have to do this with platforms that continuously expands and changes underneath their abstraction. So theres a certain amount of instability by design.

    My hope is that Microsoft at some point acknowledges this, and perhaps add a Forms sub-framework (?) with the UI paradigm of google's flutter (https://flutter.io) where all controls, layouts, etc are made using Skia and therefore independent of the underlying platform controls. This would be more robust and have variety of good use-cases. In such a paradigm the native platform controls could be the exception and not the norm.

    Thursday, June 8, 2017 1:19 PM
  • User275358 posted

    @void said:

    but I think that there will always be a certain amount of pain that you as a developer will need to live with.

    Yeah, that's part of the developer's job. But please let's not mix up the usual challenges with Xamarin Forms still not being to draw the borders of a Button correctly in all versions of Android. There's a very recent fix, like a week ago, for that, which hopefully will go soon into the released package. And this is only an example, there are several others referring to bug in controls or incomplete basic features. And of course, again there's the performance issues(converting all renderers to the new "fast" renderers should be a priority).

    Again: I am NOT pointing any fingers at the Xamarin Forms team members. The team is too small, very small, I wish the team got bigger soon after Xamarin joined Microsoft. More than 1.3 years passed and that didn't happen. Meanwhile, Xamarin has been promising A LOT of crazy new stuff while implementation for Android and iOS still has issues.

    @void said: My hope is that Microsoft at some point acknowledges this, and perhaps add a Forms sub-framework (?) with the UI paradigm of google's flutter (https://flutter.io) where all controls, layouts, etc are made using Skia and therefore independent of the underlying platform controls.

    You mean Silverlight-like where buttons for example are not native but drawn by painting brushes? Oh please for God's sake, no!

    Thursday, June 8, 2017 2:00 PM
  • User130 posted

    Hi all, there's a lot here, but let me give you a general update on what we are working on now and have been since Build.

    Quality. Period.

    The reason you're not seeing movement on feature PRs is our core team is only working on fixing bugs and improving quality. This extends beyond commits to Support and CI and QA and Testing processes as well. Issue reports incoming have been steady or dropping, and we are making great progress on the overall backlog of issues. Numbers aren't everything, but it's one metric I'm reporting on. Priority and severe issues (performance, crashes, leaks, volume of users impacted) is another and the team is clearing tons of those.

    The blog is a marketing and education channel. It is not an indicator of what the core engineering team is doing on a daily basis.

    Tizen is a contribution by Samsung. WPF and GTK# are contributions by contractor teams. Our core engineering team is not actively coding on those.

    We are hiring.

    I hope this small update helps balance the perspective on what is currently happening on the platform.

    What does this mean for the feature roadmap and the things announced as a part of 3.0? As we have always said, the roadmap will change as needed but it communicates our intention and the current roadmap is still just that. If or when any of those features need to slip to a future target, or we juggle the priority of anything else, I'll update the roadmap.

    What the roadmap doesn't indicate is anything beyond features, and I need to improve how I communicate the non-feature work. Please know that the desire for improved quality, stability, and performance is very much shared and driving our day to day efforts.

    Thursday, June 8, 2017 3:22 PM
  • User275358 posted

    @DavidOrtinau said: The reason you're not seeing movement on feature PRs is our core team is only working on fixing bugs and improving quality. This extends beyond commits to Support and CI and QA and Testing processes as well. Issue reports incoming have been steady or dropping, and we are making great progress on the overall backlog of issues. Numbers aren't everything, but it's one metric I'm reporting on. Priority and severe issues (performance, crashes, leaks, volume of users impacted) is another and the team is clearing tons of those.

    I just hope the practice of marking a bug as FIXED or COMPLETED on Bugzilla when the issue it's actually not fixed nor complete, goes away.

    If you want to have Bugzilla as purely feedback forum, like the "user voice" site, then fine, but state that clear. Otherwise it's not OK to mark bugs as FIXED or COMPLETED with a message like "we're already working it". If you're working on it, it's not complete. While an open issue might not look OK on the statistics, by closing an issue like that you're showing the middle finger to the developer who spent time reporting.

    The blog is a marketing and education channel. It is not an indicator of what the core engineering team is doing on a daily basis.

    I am not sure what you mean by that. I should not take the blog seriously? Also, marketing? What are you guys selling?

    Tizen is a contribution by Samsung. WPF and GTK# are contributions by contractor teams. Our core engineering team is not actively coding on those.

    I was aware of that. But given the fact that you don't have time to evaluate PRs for features much more important than WPF support, it would make sense to honestly communicate that while you're announcing WPF support, that's just a contributor PR, something you might even have time to take a look at. Although, it was funny to see how easily the WPF PR was accepted. But If I were to start using it to tomorrow, I have no idea though what's supposed to work or not....

    We are hiring.

    Yep, like I already mentioned, thumbs up for that. And again, I hope the # of positions is at least 5 or 7. The most important aspect however remains the architecture and performance. Hiring more people won't fix the issues if things continue to be in 20 different directions, Xamarin Forms will continue to be Jack of all trades, master of none.

    I hope this small update helps balance the perspective on what is currently happening on the platform.

    Honestly? It doesn't help.

    If or when any of those features need to slip to a future target, or we juggle the priority of anything else, I'll update the roadmap.

    OK, I hope the ball called "CSS-Like Styling" is dropped in the juggling process and gets broken into pieces.

    What the roadmap doesn't indicate is anything beyond features, and I need to improve how I communicate the non-feature work. Please know that the desire for improved quality, stability, and performance is very much shared and driving our day to day efforts.

    I am positive Xamarin can pull it off. Even though Xamarin Forms was a framework nobody believed in and took Xamarin by surprise :)

    Thursday, June 8, 2017 4:58 PM
  • User2267 posted

    @void said: I'm very fond of Xamarin and Forms in particular. You can be very productive but I think that there will always be a certain amount of pain that you as a developer will need to live with.

    The task that Microsoft is undertaking is a huge one. They have to abstract away the differences of multiple platforms while ensuring you can get to the metal. And they have to do this with platforms that continuously expands and changes underneath their abstraction. So theres a certain amount of instability by design.

    My hope is that Microsoft at some point acknowledges this, and perhaps add a Forms sub-framework (?) with the UI paradigm of google's flutter (https://flutter.io) where all controls, layouts, etc are made using Skia and therefore independent of the underlying platform controls. This would be more robust and have variety of good use-cases. In such a paradigm the native platform controls could be the exception and not the norm.

    Worked for Sun with Java too....kinda. It's the ole AWT vs. Swing. It will also lead to a revival of the native look and feel discussions that plagued Swing. 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. I just don't think it can be sustained in the long term. I'd wager my house that will prove to be the case. They will either have to use an approach like you recommend or go with a lightweight implementation that isn't so ambitious. There are some lightweight approaches they could develop that would take a lot of the extra work out of developing cross-platform apps without all of the complexity.

    Thursday, June 8, 2017 5:19 PM
  • User275358 posted

    @DavidCaraway said: Worked for Sun with Java too....kinda. It's the ole AWT vs. Swing. It will also lead to a revival of the native look and feel discussions that plagued Swing.

    Swing!? Yes, "plague" is the appropriate word.

    The current implementation is too ambitious and too prone to bugs. You can almost say it's the nature of the beast. I just don't think it can be sustained in the long term.

    No, the implementation is not too ambitious. It's buggy because XF team was too small and because XF team was poorly managed, they were out of focus. It's not the fault of the team members though. Xamarin is now hiring, which is good, but it's not going to fix the problems unless they get help from good architects, Microsoft peeps involved in other XAML frameworks, preferably Windows Phone.

    Someone has actually tried to do something similar to Xamarin Forms: https://github.com/Appercode/Appercode.UIFramework It's amazing work I came across by accident recently. I tried to look over the code, it's amazing what one or two people I think could put together. Also, try look at the architecture a bit and compare it with Xamarin Forms's, it's very interesting.

    I'd wager my house that will prove to be the case.
    Don't. You will lose your house.

    There are some lightweight approaches they could develop that would take a lot of the extra work out of developing cross-platform apps without all of the complexity.

    Those "lightweight" approaches are horrible. A more appropriate way to call them is "laughable approaches". Drawing controls using brushes and drawing text with GUI functions is terrible. That's not native, for example that's not a real button, it's just some rectangle drawn with some brush and a text drawn with some "DrawText" method. Let's keep Silverlight dead for good. Please. With a control which is not an actual native control, you will lose all the native capabilities. And you must think about ALL kind of capabilities, like accessibility and what not.

    Thursday, June 8, 2017 5:43 PM
  • User2267 posted

    @fabior said:

    @DavidCaraway said: Worked for Sun with Java too....kinda. It's the ole AWT vs. Swing. It will also lead to a revival of the native look and feel discussions that plagued Swing.

    Swing!? Yes, "plague" is the appropriate word.

    The current implementation is too ambitious and too prone to bugs. You can almost say it's the nature of the beast. I just don't think it can be sustained in the long term.

    No, the implementation is not too ambitious. It's buggy because XF team was too small and because XF team was poorly managed, they were out of focus. It's not the fault of the team members though.

    Might be a case of both

    Xamarin is now hiring, which is good, but it's not going to fix the problems unless they get help from good architects, Microsoft peeps involved in other XAML frameworks, preferably Windows Phone.

    Someone has actually tried to do something similar to Xamarin Forms: https://github.com/Appercode/Appercode.UIFramework It's amazing work I came across by accident recently. I tried to look over the code, it's amazing what one or two people I think could put together. Also, try look at the architecture a bit and compare it with Xamarin Forms's, it's very interesting.

    I'd wager my house that will prove to be the case.
    Don't. You will lose your house. No I won't

    Those "lightweight" approaches are horrible. A more appropriate way to call them is "laughable approaches". Drawing controls using brushes and drawing text with GUI functions is terrible. That's not native, for example that's not a real button, it's just some rectangle drawn with some brush and a text drawn with some "DrawText" method. Let's keep Silverlight dead for good. Please. With a control which is not an actual native control, you will lose all the native capabilities. And you must think about ALL kind of capabilities, like accessibility and what not.

    Drawing controls was hardly my idea of a lightweight approach. I've been using homemade "lightweight" approaches since the time I first started using Xamarin. They are admittedly laughable though. I don't care. I work on my own dime. I go with what works. It's been a very long time since I've ever banged my head against the wall for days trying to find a workaround.

    So we disagree on things. Such is life in technology. Only time will tell. I hope I'm wrong and have to eat a big helping of crow. XF will be awesome if they can actually pull it off.

    Thursday, June 8, 2017 6:29 PM
  • User275358 posted

    @DavidCaraway said: So we disagree on things. Such is life in technology. Only time will tell. I hope I'm wrong and have to eat a big helping of crow. XF will be awesome if they can actually pull it off.

    I was going to argue that the right question is "when", not "if". But I think you're right. Anything in regards with technology has a deadline. Even if you do it, it might be too late, so yeah maybe "if" is correct.

    Thursday, June 8, 2017 7:48 PM
  • User125713 posted

    @fabior @DavidOrtinau @MigueldeIcaza The image above is the Android hierarchy view of "Hello world" for Xamarin Forms (as is). It is 13 layers deep. For hello world. Our app, which is a pretty simple Tinder-like interface (one picture, few buttons, and some text) was several pages wide and would even crash hierarchy viewer OOM. We moved it out of XF into one giant custom renderer and now it's flat and fits in one page.

    If you actually publish a purely XF app to the app store (rather than just building hello worlds), the google play developer console gives you warnings of slow UI threads over 50% of the time. ^ this is after a month of XF-only optimization. We've moved away from XF now.

    I can't imagine how badly more complex apps are doing but I'm sure it won't be long before Google starts flagging those apps as underperforming.

    Our team filed some of the original perf bugs in early 2016 but there really hasn't been enough progress on perf to reflect 12 months of work. So I agree with the other posters above that it's very frustrating when the Xamarin blog (and visual studio) keep bringing up new features when the core functionality is not production-grade.

    <