Quick Links

Xamarin.Forms Feature Roadmap

Posts

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

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

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.

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

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.

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.

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.

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

revert to wpf naming and redo everything one on one that this framework do like important datatype on datatemplate that you are missing etc..

make it work perfectly over wpf on windows 7

stability

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

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!

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.

@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

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

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

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

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().

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 [email protected]

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 [email protected]

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 )