Bug 46373 - Windows 8.1 RT app running on same desktop as UWP app reports a different TargetIdiom
Summary: Windows 8.1 RT app running on same desktop as UWP app reports a different Tar...
Alias: None
Product: Forms
Classification: Xamarin
Component: Forms ()
Version: 2.3.2
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Paul DiPietro [MSFT]
Depends on:
Reported: 2016-11-03 11:33 UTC by John Hardman
Modified: 2017-06-20 19:41 UTC (History)
4 users (show)

Tags: WinRT 8.1 TargetIdiom Desktop
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description John Hardman 2016-11-03 11:33:50 UTC
Running on the same Windows 10 desktop PC, a Win 8.1 RT app reports TargetIdiom.Tablet, whereas a UWP app reports TargetIdiom.Desktop. Whilst that may match the comments on TargetIdiom (see below), it is inconsistent and unexpected to most developers (it was to me when I first noticed it, and somebody else has been asking about it in the forums today). Win 8.1 RT should report Desktop if the app is running on a desktop.

        // Summary:
        //     (Unused) Indicates that Forms is running on an unsupported device.
        Unsupported = 0,
        // Summary:
        //     Indicates that the width of the iPhone, iPod Touch, Windows Phone, or Android
        //     device on which Forms is running is narrower than 600 dips.
        Phone = 1,
        // Summary:
        //     Indicates that the width of the iPad, Windows 8.1, or Android device on which
        //     Forms is running is wider than 600 dips.
        Tablet = 2,
        // Summary:
        //     Indicates that Forms is running on a UWP app on Windows 10.
        Desktop = 3
Comment 1 John Hardman 2016-11-03 11:41:44 UTC
This seems to be the bit of code responsible (in Forms.cs). For UWP is tries to detect the platform, otherwise it defaults to TargetIdiom.Tablet

			Device.Idiom = TargetIdiom.Tablet;
			Device.PlatformServices = new WindowsPlatformServices(Window.Current.Dispatcher);
			Device.Info = new WindowsDeviceInfo();

			switch (DetectPlatform())
				case Windows.Foundation.Metadata.Platform.Windows:
					Device.Idiom = TargetIdiom.Desktop;
				case Windows.Foundation.Metadata.Platform.WindowsPhone:
					Device.Idiom = TargetIdiom.Phone;
					Device.Idiom = TargetIdiom.Tablet;
Comment 2 Paul DiPietro [MSFT] 2017-03-01 18:58:37 UTC
This is something that would probably need to be discussed by the team to see how it should be handled, as it could affect some developers. It should be noted that the Windows.Foundation.Metadata.Platform API is also only available in Windows 10, though, which would explain its use in the #ifdef. I do agree that it can be deceptive and that at the very least the docs should reflect the differences if they don't already.
Comment 3 Rui Marinho 2017-06-20 19:41:45 UTC
Thank you for taking the time to submit this report. After reviewing the description of this bug, we believe it no longer affects the current version of Xamarin.Forms. If you are still experiencing the issue after updating your packages, please reopen this report with an attached reproduction. 
Here are some reproduction best practices: https://gist.github.com/jassmith/92405c300e54a01dcc6d