Forum Libraries, Components, and Plugins

Platform Compatibility List

I was headed down the road of trying to use UrhoSharp (Forms) across all platforms including Win8.1, WinPhone8.1, Win10UWP, and WinPhone10UWP as well as iOS and Android. I now get the impression from the answer to a question below that this isn't possible. Can we get a definitive list of precisely which platforms are supported by UrhoSharp and UrhoSharp Forms? It might also be very useful to post this list prominently on the UrhoSharp introductory page(s) on the web site -- where most people start out looking at UrhoSharp. Thanks!

Answers

  • EgorBoEgorBo BYXamarin Team ✭✭✭

    The full list of the supported platforms is:
    1) iOS - armv7, arm64, i386 - fat lib.
    2) Android - armeabi, armeabi-v7a, x86, x86_64, arm64-v8a
    3) Windows (classic apps) - x64 (nuget package also contains the x86 lib, but switching between them is not obvious)
    4) macOS (i386, x86_64 - fat lib) can be used in Cocoa based apps.
    5) HoloLens (x86 only)
    6) UWP (x86 only, no ARM so it means - no Windows Phone)

    UrhoSharp for Xamarin.Forms supports:
    1) Android
    2) iOS
    3) UWP (x86 only).

    Thank you for the suggestion - I'll add this info somewhere in the docs.

  • Thanks, Egor. Do you know of anyone who has been successful using SharpDX with Xamarin.Forms -- at least for the Win/WinPhone variant of the app? Or rather, is there any reason to believe it's a dead-end approach?

  • JulianWinterJulianWinter GBMember ✭✭

    Egor, Is there any specific reason why iOS and Android ARM is supported, but not Windows10 (UWP) ARM ?

  • EgorBoEgorBo BYXamarin Team ✭✭✭

    @JulianWinter said:
    Egor, Is there any specific reason why iOS and Android ARM is supported, but not Windows10 (UWP) ARM ?

    I've not tried it yet but it should be possible, I am refactoring my SDL changes for UWP now, I am not promising but I'll take a look.

  • Considering MSFT called me as part of a survey wanting to know how to make VS better for UWP development, I think more of the answer resides in the framework(s) surrounding VS and not VS itself so much. Between .NET Core and Xamarin I'd think a goal should be the ability to write one single application that can run on all platforms "as is" (source wise).

    As a developer I'd prefer the approach where I can completely ignore platform differences (as nearly as possible) during initial development, and have the app "just run" on all platforms even if the UI isn't in that platform's style. Some apps even have their own style non-related to the platform's style. Games are often like that. Fire up a game app, and the entire thing is in its own style.

    The idea being the developer can get one common code base running across all platforms, and then LATER layer-on some tweaks here and there to make the app more style-common to the platform if desired.

    Xamarin has a great idea, but it's approach is to wrangle a bunch of platform UIs simultaneously right out of the gate while trying to get the core logic/concept working. That's a lot of overload straining the developer's focus. If some library on top of .NET Core could be relied upon to provide a common UI even if it wasn't tailored to each platform's style, that'd help get apps up and running. Let the developer tweak the UI later with anything platform specific they want to do after all the core functionality is working.

    MSFT will have more success with app support for MSFT mobile devices if the developer can write and debug a single app codebase within the Windows (including Windows Mobile) environment, and then know the app will "just run" on the other platforms "as is". This approach means developers are cranking out Windows apps by default as part of the development process, so there's no reason to not submit them to the Windows app store.

    In fact, if a .NET Core UI library can provide the core platform independent UI, then ideally any platform-specific UI the developer adds to their app should use a concept like virtual in derived classed (conceptually, maybe not literally). This could be ideal for debugging. At any given time the developer can somehow "unplug" the platform customized UI and run the generic UI on any platform to cross-check whether any bugs may be related to the platform customized UI. Much of unit testing might rely upon using the generic UI for consistency when testing the underlying logic rather than the UI itself.

Sign In or Register to comment.