Forum Xamarin.Forms


The Xamarin Forums have officially moved to the new Microsoft Q&A experience. Microsoft Q&A is the home for technical questions and answers at across all products at Microsoft now including Xamarin!

To create new threads and ask questions head over to Microsoft Q&A for .NET and get involved today.

Xamarin.Forms 1.3.3 Released

TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai


  • Deeply nested Grid performance enhanced

Bug Fixes

  • Bug 21606 - Page Title not updating when set in OnAppearing() Method the second time page is displayed. (iOS)
  • Bug 20798 - ListView TextCell.DetailProperty only wraps on Android
  • Bug 24777 - jobject must not be IntPtr.Zero exception when replacing Content of a Page
  • Bug 26214 - On Android, InputTransparent=true does not work with ScrollView
  • Bug 22673 - Initially hidden BoxView when made visible does not render (but does take up space in the UI)
  • Bug 25703 - Webview waits to load the content until webviews on previous pages are loaded
  • Bug 26139 - Navigation.RemovePage() still shows the back button on Android
  • Bug 26304 - System.ArgumentNullException thrown when moving items in an ObservableCollection that is observed by a ListView
  • Bug 26064 - ListView, ImageCell and disabled source cache and same image url leads to degraded performance
  • Bug 26121 - Android ListView.ScrollTo doesn't work when ListView inside TabbedPage
  • Bug 26501 - Context Actions cause views to be hidden on iOS after re-use
  • Bug 23585 - [Android] ListView not updated when ObservableCollection is modified

Other Fixes

  • [Core] CarouselPage now has more informative error when used without Children
  • [Android] BoldItalic text now works as expected
  • [Android] HeaderCells no longer tapable in TableView
  • [Android] Fix NullReferenceException when re-using ListView on second page
  • [iOS] SearchBar cancel button hides if there is nothing to clear
  • [iOS] EntryCell Completed event fires twice
  • [iOS] Fix potential crash with Editor inside of a ScrollView
  • [iOS] Fix potential crash when ScrollView is inside of ViewCell
  • [iOS] Fix issue where ContextActions could end up out of order
  • [WP] Keyboard action for search does not match other platforms
  • [Xaml] Text as content property now properly trims whitespace
  • [Xaml] Duplicate x:Name's throw a more informative error now
  • [Xaml] Better error on Type mismatch for


  • DH_HA1DH_HA1 USMember ✭✭✭

    @TheRealJasonSmith excellent work you and the forms team are doing!

  • BrianMedleyBrianMedley USMember ✭✭

    Thank you for the recent updates and the transparency.

  • aaragaoaaragao BRMember

    Hi Guys, after I updated my app solution from 1.2 to 1.3.3 I'm getting the following error when I try to execute: "MonoTouch.Foundation.MonoTouchException: Objective-C exception thrown. Name: NSInvalidArgumentException Reason: -[__NSDictionaryI __setObject:forKey:]: unrecognized selector sent to instance 0x7c7244f0".

    Any one can help me on this? Thanks a lot.

  • @aaragao Did you get this error cleared up? I'm having the exact same issue.

    Would love to hear from Xamarin on this one...

  • Yay - with master/detail on tablet the menu closes itself again! :)

  • @DanielNelson.9924 What did you need to change on the master/detail to fix this issue?

  • GaborFurediGaborFuredi HUMember ✭✭
    edited February 2015

    Same here! Actually the exception came for me at my appdelegate's last line according to the debugger:

    return base.FinishedLaunching(app, options);

    After Googleing, I've found @ChrisExigent's other forum post ( That led me to the root cause of setting the BarTextColor property on a NavigationPage when I'm creating the detail view for my MasterDetailPage. If I set the BarTextColor, I get the aforementioned exception.

    If I simply comment that line, my app works as before the 1.3.3 upgrade.

    @TheRealJasonSmith I would be very interested to hear how you guys are testing new releases before they come out in the 'stable' branch. Either these breaking changes should be documented properly, or you guys really need to do more thorough testing before releasing these updates. I often feel we are guinea pigs on the stable branch and things are breaking which were working previously, which is not acceptable and sustainable at all.

    By the way, the issue at the heart of the matter I believe is that you are creating an NSDictionary somewhere instead of an NSMutableDictionary, and you try to add elements to the NSDictionary after initialization; which is not possible, hence the 'unrecognized selector' error message.

  • TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai

    @GaborFuredi every release goes through a week in pre-release and a week in QA. Passes a battery of regression tests and is tested against a large internal test suite. Whats interesting is better 1.3.2 and 1.3.3 no change was made to the BarTextColor code path. I am looking into the issue right now.

    We are not creating an NSDictionary anywhere in forms, I don't want to speculate too much on the cause of the issue at this time. I will post back shortly with an update.

  • GaborFurediGaborFuredi HUMember ✭✭

    Thanks for the quick response. Interestingly enough, commenting out the BarTextColor property only helped on the simulator, on the device I'm still getting the exception. Now I'm in the process of hunting.

  • TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai

    I just validated this code runs fine for me on device:

            var searchBar = new SearchBar ();
            var stack = new StackLayout {Children = {searchBar }};
            MainPage = new MasterDetailPage () {
                Master = new ContentPage {Title = "Master"},
                Detail = new NavigationPage (new ContentPage {Content = stack, Title = "Purple"}) {
                    BarTextColor = Color.Purple

    Is there something else I need to do to reproduce the issue? What device are you testing on? What simulator?

  • TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai

    I have further validated the code runs on sim (I rarely test on sim because the iOS 8 sims are so buggy its not worth it)

  • GaborFurediGaborFuredi HUMember ✭✭

    In the meantime I've verified the bug on the device as well, it just turned out on the device I was on a different code path which had another BarTextColor as well, not the same one I've commented out in the use-case I've tested on the simulator.

    After commenting out the BarTextColor there as well, now the app runs on the device properly.

    The simulator is 8.1, the device is iPhone 5 with iOS 8.1.3.

    I will create project for you to reproduce.

  • GaborFurediGaborFuredi HUMember ✭✭
    edited February 2015

    @TheRealJasonSmith I've got another lead. I've just created the repro project, uploaded here:

    All I needed to do is to modify the navigationbar with the native iOS API, then BarTextColor starts causing crash. I've put the following into the AppDelegate in the repro project now:

    UINavigationBar.Appearance.SetTitleTextAttributes(new UITextAttributes{Font = UIFont.SystemFontOfSize(16),

    Crash is reproducible both in the simulator and on the device.

    Please note, this crash did not happen before 1.3.3.

  • TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai

    thank you @GaborFuredi please give me a couple to dig in to this.

  • TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai
    edited February 2015

    @GaborFuredi I have reproduced the crash and will create a regression test case for it. Testing this particular mix of UIAppearance and Forms was not previously being done (hence how it managed to break). Unfortunately its simply not possible to test the billions of ways to combine all the base API's and Forms API's together, but we do our best. I will get this fixed in 1.3.4 as its a regression from 1.3.3. In general, we don't recommend setting the same values from both UIAppearance and Forms if you can avoid it.

    Edit- And as a bit of post mortem, the bug was introduced when we had to port to Xamarin.iOS for XF 1.3.1. This is due to the API we were using going away and the new API seemingly having different semantics in some fashion I have not quite figured out yet.

  • GaborFurediGaborFuredi HUMember ✭✭
    edited February 2015

    @TheRealJasonSmith Thanks, I appreciate the swift response. I would say using UIAppearance to customize the navbar is pretty common in real life apps though as not everything is accessible via the Forms equivalent. Also as I mentioned above, I'm quite sure this is an NSDictionary - NSMutableDictionary issue somewhere.

    EDIT: I've just seen your suggestion to avoid setting the same values from both UIAppearance and Forms. I've tried to only set the Font from the UIAppearance instead of setting both the Font and the TextColor, but there's no difference in the result.

    @ChrisExigent , @aaragao are you guys also customizing the UINavigationBar with native APIs just like I do?

  • TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai

    @GaborFuredi you are right yes :) It turns out that by setting UIAppearance the API we were using to grab attributes from the theme is now returing a non-mutable dictionary. I have resolved the issue and will get it into 1.3.4-pre2

  • GaborFurediGaborFuredi HUMember ✭✭

    @TheRealJasonSmith Excellent, thank you :)

  • KrisWattsKrisWatts AUMember
    edited February 2015

    Hey, I'm currently getting a problem as of updating to 1.3.3. When build for the android store, i get:

    /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.targets: Error: Error executing task LinkAssemblies: error XA2006: Reference to metadata item 'System.Void Android.Widget.AbsListView::SetSelectionFromTop(System.Int32,System.Int32)' (defined in 'Xamarin.Forms.Platform.Android, Version=, Culture=neutral, PublicKeyToken=null') from 'Xamarin.Forms.Platform.Android, Version=, Culture=neutral, PublicKeyToken=null' could not be resolved. (Axon.Droid)

    Works fine for debug. Build target is 4.4.

  • TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai

    @KrisWatts make sure your TargetFrameworkVersion is set to API 21, as well as your compile version, make sure your minimum is at least 14 and that you have the latest Android SDK installed. Xamarin.Forms requires the latest Android build sdk to work.

  • AlessandroCaliaroAlessandroCaliaro ITMember ✭✭✭✭✭

    @TheRealJasonSmith When I've updated the SDK and Xamarin Studio, now I've this error in RELEASE mode

    D:\Documenti\software\CSharpApp\ACaliaro\Crossware\Geco\Geco\packages\Fody.1.27.0\build\Fody.targets(5,5): Error MSB4044: all'attività "Fody.WeavingTask" non è stato assegnato un valore per il parametro obbligatorio "DefineConstants". (MSB4044) (Geco)

    TargetFramework is "latestInstalled 5.0"
    MinimumAndroidVersion is 4.1 Api level 16

    I've opened a Bug in Bugzilla

    Try to remove and reinstall fody package but nothing change

    I can't build the apk...


  • TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai

    I would need to see your release build, but it looks like Fody requires a for the of your active build config. Make sure all your build configs have this, its possible during the upgrade XS somehow re-wrote your .csproj file to remove it?

    Either way this is not strictly speaking an incompatibility with Forms, but I hope get the changes to your csproj made that Fody seems to need. (Try adding a RELEASE define like you have a DEBUG define)

  • AlessandroCaliaroAlessandroCaliaro ITMember ✭✭✭✭✭

    @TheRealJasonSmith thanks for the answer.
    What you mean by "see your release build". Do I have to attach a file? Or a screenshot?
    I don't understand "looks like Fody requires a for the of your...". Requires what?
    No, no one have re-wrote the csproj.
    "Try adding a RELEASE define like you have a DEBUG define". Where do I have to add this define?

    Sorry for these questions....

  • TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai

    @AlessandroCaliaro send my your csproj file please

  • AlessandroCaliaroAlessandroCaliaro ITMember ✭✭✭✭✭

    this is it

  • NicholasRogoffNicholasRogoff GBUniversity ✭✭

    Is there a detail change log for each version of Xamarin Forms. I am trying to work out if any controls have new properties and when they came in.

    Also can you tell me what this obsolete tag mean on the Xamarin.Forms.Label.Font Property

    [System.Obsolete("Please use the Font attributes which are on the class itself. Obsoleted in v1.3.0")]
    public Font Font { get; set; }

    I am working on the XLabs project and need to know if enhancements made there are now baked in to the latest releases.


  • DavidTavarezDavidTavarez DOMember ✭✭✭

    ToolbarItems do not display on Device (iPhone 4S, iOs 8.1)

    Development market : 7.0

  • DavidTavarezDavidTavarez DOMember ✭✭✭

    This is the code.

    `var drawer = new ToolbarItem () {
    Text = "drawer",
    Icon = Device.OnPlatform ("Toolbar/drawer.png", "drawer.png", "drawer.png"),
    Priority = 0
    drawer.Clicked += async (sender, e) => await Navigation.PushModalAsync (new MenuPage ());

            var join = new ToolbarItem () {
                Text = "join",
                Icon = Device.OnPlatform<string> ("Toolbar/join.png", "join.png", "join.png"),
            join.Clicked += async (sender, e) => {
                var result = await App.BarCodeService.Read ();
                if (result.Success) {
                    await App.DialogService.AlertAsync (String.Format (
                        "Bar Code: {0} - Type: {1}",
                } else {
                    await App.Notificator.Notify (Toasts.Forms.Plugin.Abstractions.ToastNotificationType.Error, 
                        "Error", "No se pudo obtener la Cámara", TimeSpan.FromSeconds (2));
            var create = new ToolbarItem () {
                Text = "create",
                Icon = Device.OnPlatform<string> ("Toolbar/add.png", "add.png", "add.png"),
                Priority = 2
            create.Clicked += async (sender, e) => await Navigation.PushModalAsync (new MenuPage ());
            ToolbarItems.Add (drawer);
            ToolbarItems.Add (join);
            ToolbarItems.Add (create);`

    Is not working on device just on the Simulator.

  • DavidTavarezDavidTavarez DOMember ✭✭✭

    Oh, there is something with icon. When I remove the Icon property it shows perfectly but without icon.

    Also Toast plugin is not showing the images.

  • TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai
    edited February 2015

    @NicholasRogoff we did not add any new API this release. We will specifically call out new/changed API in release notes if there is any. That obsolete tag basically means instead of using Label.Font, use Label.FontSize/FontAttributes/FontFamily.

    @DavidTavarez are you sure your icon is ending up inside your app bundle? We have seen users having issues with this lately. Unfortunately this is not really a Forms specific thing, however the iOS team is aware of the issue.

  • @GaborFuredi @TheRealJasonSmith changing the color of the UINavigationBar is fundamental. Still shaking my head as to why this broke.

  • TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai

    @ChrisExigent it was broken because we didn't have a regression test that tested setting both at the same time? I know it must seem trivial to test every possible combination of forms and non-forms APIs, but it really isn't practical. We do however do our best to make sure that when something like this happens a new regression test is entered. This issue was made worse by the Xamarin.iOS Unified API changes, which were the cause of the incompatibility to begin with (we had to switch to a new API that had slightly different semantics but we didn't realize that at the time of the switch).

    Im truly sorry this has disappointed you, I feel we have reacted in an extremely fast manner as soon as it was raised to my attention. If there is anything else I can do please let me know.

  • KevinFordKevinFord USUniversity, Certified XTC Partners ✭✭✭
    edited February 2015

    From what I've seen the 1.3.x series has been a great improvement in the stability of the library. It's to the point where we are recommending it for more situations to our clients. The library is coming into place nicely and becoming more predictable. Also the third party and community tooling and support is starting to hit critical mass.

    I've got to hand it to @TheRealJasonSmith , since the beginning of the year he appears to have been focusing on bug fixes and stabilization and making the product very nice to use. He's got a very small team and if you read what he's doing process wise here; he's making the right moves for release stabilization, particularly around test/unit testing and regression control.

    It will still take some time to settle down so expect that there will be some regressions (which be the way, as a user of the library I am able to control by making decisions on when to hold off and when to get the newer versions). With a couple week iteration cycle and a small team there will probably always be some level of churn but the product is maturing nicely.

  • @KevinFord @TheRealJasonSmith Xamarin without a doubt is doing great things with their product. My issue however is with every release there are issues that cause me to spend days to fix. I paid real money for this product and I am building real apps for real consumers, that rely the product. With every release there are major setbacks. I expect more from Xamarin. I dont think this is too much to ask. With the recent update to 1.3 and the corresponding issues that were found not only in the library but Visual Studio as well, its very disappointing.

  • TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai

    Did you figure out your issue with 1.3.4? Do you still need support? I know the support team is in touch with you, but we can directly touch bases if need be to resolve whatever issues your app is having. As far as I can tell you have not replied to our last attempt to help you?

  • MikeEEEMikeEEE USMember ✭✭✭

    I also wanted to chime in here and say that I jumped into the Xamarin.Forms 1.3.x release and have been very impressed with it. Much appreciation and respect to the @TheRealJasonSmith and the Xamarin.Forms team. It's just incredibly awesome what you have done and it is great to be able to start developing real applications that have meaning and value. This hasn't been the case since Silverlight5 (which, if you're counting at home, is 4 years "removed" from this April!).

    My only question here is the use of the async pattern in some of the interfaces that have changed since Xamarin.Forms 1.2.x. I know async is awesomely better than what we used to have, but once you introduce async into your codebase, you end up with zombie async codebase that ends up being async "all the way down."

    This is just a consideration and something I just want to throw out there. I know I am probably in the minority, but seeing "async" and "Task<>" (and also the "MethodNameAsync" convention, just in case you couldn't already guess it's async. :P ) as implementation details on interfaces makes design noisier and (again, IMO) harder to look at/read.

    The alternate obvious consideration is to keep interfaces synchronous but then wrap them in a Task at the point of usage.

    There might obviously be a consideration here that I am unaware of, so take it for what it's worth. :)

    Also (and much more importantly!), I am concerned about platform integration moving forward, as it appears that in order to extend Xamarin.Forms to another platform (WPF or HTML5, for instance), that a lot of functionality and integration points are marked as internal. I am curious on why this is and if this is going to be addressed relatively soon. There are also things such as the TargetPlatform enumeration that make it seem like there are just a finite number of platforms that Xamarin.Forms is intended to run on... which is concerning. :/

    Anyways, that's really about it. Again, I am so appreciative of the work and vision done on this project and the progress that has been made, especially considering the team and the tasks at hand!!!

  • DrazenDotlicDrazenDotlic FRUniversity ✭✭

    Im truly sorry this has disappointed you, I feel we have reacted in an extremely fast manner as soon as it was raised to my attention. If there is anything else I can do please let me know.

    @TheRealJasonSmith From what I've seen in the thread you were very responsive and worked on the issue with the user until it was resolved.

    As software developers, we must understand the impossibility of testing every possible API combination, I'm with you on that.

    I guess the other user's frustration was with 'essential' feature broken, not the matter it was handled.

    Either way, know that there are others who appreciate your work and work of your colleagues on the Forms team. I am pleasantly surprised by the number of issues fixed and new features implemented by such a small team.

    Yes, we're seeing regressions and new bugs created all the time but I think this is simple to fix - for me personally, 1.3 is more or less feature complete, now just work on fixing bugs and regressions and your user base happiness will dramatically increase.

  • TheRealJasonSmithTheRealJasonSmith USXamarin Team Xamurai

    @MichaelDeMond the TargetPlatform enumeration will be expanded as we add more platforms. So yeah, dont dep on that thing being the same size forever. As for the internal parts, its just we have not yet had a chance to vet those API's as best we can for backwards compat and usefulness. Rather than be stuck with something we think might have to change we marked it internal so we could change it before we mark it public.

    We fully intend to remove all, ALL, internal APIs. We have already started this with the IViewController series of interfaces, and are going to continue working through those. The platform interfaces will be next.

    @DrazenDotlic thank you for the kind words, the entire team really appreciates it :)

  • MikeEEEMikeEEE USMember ✭✭✭

    Thanks @TheRealJasonSmith for your answer, and for engaging your users! Especially on a weekend. :) I know you guys are super busy, so it's always great to hear from you and to see you active in the forums.

    That's awesome to hear about your intent with platform integration. Looking forward to see how you implement this.

    My comment about TargetPlatform enumeration was more along the lines of making it more of an entity/class as a profile domain entity than an enumeration. That way, you can make as many as you want and provide all sorts of properties on it instead of switch-casing enums everywhere (messier code). (You can imagine a Xamarin.Forms.Platform.CurrentProfile singleton describing the current platform that Xamarin.Forms is running under, along with all of its capabilities and supporting information). Obviously, the point here is that if some 3rd party extends Xamarin with a new platform, it won't be dependent on updating that enumeration, recompiling/packaging and deploying another nuget release.

    But, I understand that this is only v1.0 and you have to start somewhere. Getting internals out of platform implementations is much higher up on the importance/priority factor. :) Thanks again!

This discussion has been closed.