Risks of mvvmcross vs non-mvvmcross

Hello everyone, we're just getting started with Xamarin and I am evaluating our options as far as setup and architecture for a couple upcoming projects. The project that is coming up is an ASP.NET MVC SPA app (AngularJS + WebAPI) that we'll want to build native mobile apps (iOS/Android) for in phase 2. So, we're going to have a web-app that has an extensive admin/management area that is strictly web-based, then a front-end SPA that web-users can interact with. We're hoping to use the webapi dependant service layer to communicate with the native mobile apps that we're hoping to build in Xamarin. I've investigated PCLs and understand the concepts/benefits, looks great.

Now, the question is, since we're going to want to support iOS and Android, my understanding is we can achieve greater code reuse if we use a framework like mvvmcross. I've watched the video series by the creator, and it seems like its fine frameork. A concern is that things appear to have changed since the videos were made, and I am not seeing updated examples/tutorials (although the creator seems incredibly dedicated to the project with answers/support!!). So back to the question.. is mvvmcross mature enough to use in a commercial product?

Question #2, since longevity is a major concern, would it be better for us to just stick with plain jane Xamarin iOS/Android projects and not rely on something like mvvmcross? Are we doubling the workload on our devs if we do this?

As you can probably tell, I want the answer to be that we should use mvvmcross, because I am a fan of the MVVM pattern. My biggest concern is the lack of updated tutorials which leads me to think that things are moving fast and it may be better to not use it until things settle down a bit?

I'd love to hear comments on this.

Thank-you very much in advance!


  • MarwanMarwan USMember, University

    I just started looking at this and had same question...btw, just noticed mvvmcross v3.1.1 beta released today...

  • RomanKaganRomanKagan USMember ✭✭

    MvvmCross makes development of application extremely fast, when you learn it.
    for example, it took me just a week to build almost complete product for windows 8.1, using core ready for iOs and android

  • Based on what I have read so far, it certainly seems mature enough to use in a commercial product. Aviva Insurance's RateMyDrive app uses mvvmcross. Check this out for more info and for other commercial/open source apps using mvvmcross http://stackoverflow.com/a/10225623

  • Others can correct me if I'm wrong but using Mvx isn't much different than using Mvvm-light in the sense that it's an MVVM framework only Mvx is tailored for cross platform development. So, if you didn't use Mvx you'd most likely end up writing similar MVVM functionality.

    If you look at the Mvx source it seems like a lot but it's really very light and very well thought out. So as a MVVM framework its as mature as other frameworks that have been around for a while and very extensible. If I started a new mobile project that was not xplat I'd still use Mvx.

  • SharbelWiredSharbelWired USMember ✭✭

    Great, thanks everyone for the responses. I am going to continue evaluating. Its great to hear that I've heard nothing but good things about mvvmcross so far, even in my searching online etc.

  • @SharbelWired Stuart uses Stackoverflow for questions but there's also a jabbr room, in case you didn't know. https://jabbr.net/#/rooms/mvvmcross

  • MikhailFayerMikhailFayer DEMember, Beta

    @dbeattie I went from mvvm-light to MvX and IMO it's a much more opinionated and comprehensive framework that leaves you with a lot less plumbing to invent on your own, and a plugin mechanism and community so when the framework leaves something out, there's a good chance someone else has implemented it in a reusable way. Hell it even has it's own databinding engines for all the platforms, that are richer than what Msft provides natively.

    If you prefer minimalist frameworks, I don't think you'll like MvX. For me it's vastly reduced the size of my code-base and it's level of stability/bug-free-ness is totally satisfactory.

  • softlionsoftlion FRBeta ✭✭✭

    Same here. There was some big pitfalls i fell in while learning it though. but with stuart around answering all questions, videos, demo prjects, full source code, the pluggability of the classes, the community, and the maturity of the product : it is a good choice.

  • HugoLogmans_HugoLogmans_ NLMember ✭✭✭

    It's a fine framework, especially with the latest version. But don't underestimate the learning curve. When you run into a crash, it is quite often completely undefined if it is a MvvmCross, Xamarin bug or your own fault. This can take hours to find out. After building a complex app with MvvmCross, I can tell there are (almost) no bugs you will encounter in MvvmCross, but it crashes a lot during development because of not following naming conventions :)

    As a tip: the messenger plugin is very advisable.
    And: Stuart needs to get a commitment prize of something like that :)

  • SKallSKall USMember ✭✭✭✭

    Once you have a complex application in place and for some reason do not want to use MvvmCross anymore, how quickly do you guys think you could refactor the code to remove Mvx from the codebase?

    This is usually the first risk assessment to make when selecting what tools/libraries to use.

  • OrenNovotnyOrenNovotny USMember, Insider, Beta, University ✭✭

    Not to add more fuel to the fire, but ReactiveUI is also worth checking out. For me, I liked having Reactive view models instead of dealing with INPC directly. Made things far cleaner.

    RxUI vs MvvmCross becomes a functional-reactive vs. imperative choice then.

    The latest beta of RxUI does work as a PCL with Android and iOS long as you're using the current Xamarin alpha.

  • tessierptessierp CAMember

    I started to use MVVMCross for an application I am building. I have to say it is well done and the devs answer most questions you have quite fast. That being said, with the announcement of Microsoft's Universal Apps and with talks about the possible acquisition of Xamarin by Microsoft, I have been wondering if by building my apps depending heavily on MVVMCross and that it might get abandonned should Microsoft offer something that does the same thing, is it really worth it?

    Furthermore, I have no plans to develop applications for IOS or Android for the time being. I am only using MVVMCross because it offers a nice Framework to work with while allowing me the flexibility of porting my apps faster should I decide to..

    So the risk really lies there. MVVMCross might be around for a few years or longer than that, just like support for it could stop because another bigger company like Microsoft offers something similar and becomes irrelevant..

  • RichardHopkinsRichardHopkins JPMember, University ✭✭✭

    @tessierp‌ - I'm with you on that one. You can never predict these things, but the next logical step for Xamarin and Microsoft should be (at least IMHO) a major effort to address the front-end/UI side of Xplat on a more officially supported basis. I was hoping we might hear something more at Build even if it just teased at a future project, but no luck so far.

  • tessierptessierp CAMember

    Today, Microsoft is going to talk about the future of C#, they might even talk about Project Roslyn which has to do with the concerns some of us have in regards to using a Framework that might become obsolete.

    For those who do not know about Project Roslyn, here is a Wikipedia link. Doesn't tell much except that it aims at making a compiler that is cross platform :


    Again, I am not talking about this to anger anyone working with MVVMCross or the creators / contributors of MVVMCross. It is an excellent framework and it really shows just how much effort has gone into it. It is a big and complex framework that aims to solve portability while offering a decent approach to MVVM.

    If Project Roslyn delivers what some of us may need and with the added Universal Apps, this could be a solution many of us have been waiting for. The only thing I would say I do not like about Universal Apps is that you can put XAML / UI code into the shared component. While it is true that for some apps you can reuse the same UI, 95% of the time you have to customize anyways. To me, the shared component is like MVVMCross's CORE, where all the models, business logic is. I guess its a added flexibility for those who might need it.

    What I would really like to know is how Universal Apps affect those who started coding things around PCL (Portable Class Libraries).. What I mean is, of course it will not render your code useless but, will PCL still be maintained and augmented as needed ? If someone knows, I would appreciate you share what you know.


  • tessierptessierp CAMember

    About my last post, after seeing this morning's keynote on C#'s future, Roslyn is not what I thought it was going to be, although a welcome addition...

  • SamehSameh USMember

    Consider the limitation of the Portable Class Library(PCL),
    it worth to consider the mvvm-cross and buy the limitations of the PCL (or tweak/tune your design to its limited functionality).

    for example:

      - PCL will not allow us to make any Sync Call to WebService and even to build the Request we need to make async calls ( limits by PCL and WinRT); 
      this may appear the trend now a days  ( but for building simple request string we are forced to make async call) looks strange.. 
      - at least some Encryption Classes are not available to use if you needed this ;

    of course workarounds can be done, and may be another new libraries are now added to solve issues but consider that your team will spend some time to build their libraries if they are not there.

  • BernieHabermeierBernieHabermeier USUniversity ✭✭

    For what it's worth, mvvmcross development has slowed a bit over the last year: https://github.com/MvvmCross/MvvmCross/graphs/contributors though that's not neccessarily a bad thing. If the project has reached maturity / stability then why continue to mess with it?

  • SimonHoffmannSimonHoffmann DEMember

    We've come quite far with a cross-platform app for Android and iOS with MvvmCross, but I'm seriously considering abandoning it and going back to pure Xamarin with Shared Projects.

    The main reason for that would be its handling of Android fragments, or rather, lack thereof. A short discussion can be found here: https://github.com/MvvmCross/MvvmCross/issues/636

    I felt that I had to yield control to the framework in a few critical places and hope that it does the right thing, and unfortunately it doesn't quite do that with fragments. I haven't been able to come up with a convincing solution for that, they all seemed hackish at best. Maybe it's just me.

    In addition, the more I work on Android, the more I get the impression that it's actively hostile towards MVVM patterns in general. It's just not a good fit. (Asserted without further evidence.)

    Everything else that's been said about MvvmCross here, about it being an impressive and well-thought out framework are true, however, so more's the pity. For apps up to a medium level of UI complexity, it's awesome.

  • tessierptessierp CAMember

    If you are building an application where you have to consider portability as well as being able to build complex UI, what choices are there then?

    I've looked into PRISM however, and this may be subjective, it seems heavy for smaller devices. And there is yet no support for Windows Phone 8.1 from what I have seen.

    MVVM Light and Caliburn looks great but never used them so I wouldn't be able to say just how easy it would be to create portable apps with those frameworks..

    So basically my question would be, if not MVVMCross, which framework would you take and why?

  • doridori GBMember

    I felt that I had to yield control to the framework in a few critical places and hope that it does the right thing, and unfortunately it doesn't quite do that with fragments. I haven't been able to come up with a convincing solution for that, they all seemed hackish at best. Maybe it's just me.

    The system implementation on Android for Fragments is pretty hackish & messy in itself, even without using 3rd party frameworks on top of it. Quite worrying that Mvx cant handle config changes in that case, as thats a real deal breaker. Is this just fragments or Activitys / custom views also (as these would also be subject to config changes)

  • ErikFAndersenErikFAndersen DKMember ✭✭

    I'm currently evaluating whether to stick with MvvmCross or not, because it seems that developement has slowed down a lot, and they also appear to have issues with the universal migration.

    It is true that MvvmCross does not have any good support for fragments, but to be quite frank this is not really the issue to me.

    As stated above the fragment implementation in Android is pretty hackish, and there are even people advocating not using fragments at all on Android.


    After working with fragments for the last year I tend to agree with them, and I am seriously considering abandoning fragments entirely.

    Regarding MvvmCross alternatives I am very open to suggestions as well :-)

  • softlionsoftlion FRBeta ✭✭✭

    and they also appear to have issues with the universal migration.

    None at all. 2 bigs projects migrated without issue. You have to use the nuget prerelease channel though.

    developement has slowed down a lot,

    Well it is pretty stable. But i agree that the prerelease channel should be have been moved to stable, as it is prerelease since mid january. I suppose there is issues with nuget on how to distribute mvvmcross so it can continue to work with the non migrated projects.

    But the pull requests are accepted. If the owner don't argue too much with your code having comments.

  • softlionsoftlion FRBeta ✭✭✭

    For fragments, mvvmcross implementation is not optimal. For Xamarin Forms it is nearly impossible too. I used to have my own mvvm framework which found a good way to deal with them. They have a real use. But if you can avoid them, avoid !

  • VyacheslavVolkovVyacheslavVolkov RUMember ✭✭
    edited March 2015

    Regarding MvvmCross alternatives I am very open to suggestions as well :-)

    You can try MugenMvvmToolkit as an alternative to MvvmCross. It is also a cross-platform framework but unlike MvvmCross it solves the problem of fragments on the Android platform. In addition, it has a number of other unique features.

  • Martijn00Martijn00 NLInsider, University ✭✭✭

    MvvmCross has worked on the support of Fragments, Android support libraries and Xamarin Forms lately.
    You guys can find it here: https://github.com/MvvmCross/MvvmCross-AndroidSupport

Sign In or Register to comment.