Will the UI elements look same on different platforms?

[GiantappMan]

Does MAUI look different on different platforms, just like xamarin.forms?
I wish MAUI can keep the same UI on all platforms.

[charlesroddie]

Xamarin users mostly want identical UI. The ability to make breaking changes now would allow defaults for standard controls that appear as close as possible on different platforms.

Taking a dependency on SkiaSharp would allow some controls to have a single renderer which would automatically display identically across platforms, and improve the maintainability of the XF repo. Image-related controls including Icons, Images, Shapes would be particularly good candidates.

[charlesroddie]

Actually now there is brilliant work in https://github.com/dotnet/GraphicsControls to do platform independent rendering for MAUI. When that project reaches maturity I believe a lot of MAUI developers will jump to it, to eliminate platform-dependent differences and platform-dependent bugs.

[JohnH-FF]

I have the opposite view, I want a droid button to look like a droid button on droid devices, and an iOS button to look like an iOS button on iOS devices. Users prefer a native experience, and a native look and feel.
It is not a common use case that users will have and use both devices at the same time. They do not need to look exactly the same. The layout can (and should!) be the same of course.

[davidortinau]

@Jure-BB true, I agree with your assessment though the cost depends I'd say depends on the development team's skillset. We know teams that are well versed in platform UI frameworks, and so a custom renderer is a super-power rather than a time suck. I acknowledge this has become to exception rather than the rule among Xamarin developers over time.

As such, what we aim to do is help developers a/ achieve design without diving into the 3+ frameworks, and b/ template controls with a uniform rendering as a secondary option (or primary I suppose if you already know you want it).

[butaixianran]

your point is not what most developer want. Same ui on every mobile device is the main reason why flutter is popular.

What you want, is the reason why XF is not popular.

let people on different platforms have the same experience is the meaning of cross plateform.

[charlesroddie]

@davidortinau The approach of treating platform-independent ui as secondary is a big mistake. You must know from feedback and surveys that most users want this. So treat it as primary. That means:

• Commit to Maui.Graphics.Controls as work on this is more important than the work on per-platform native handlers. Maui is ready when Maui.Graphics.Controls is ready.
• Performance considerations and metrics should be under the assumption of native rendering.

[Joebeazelman]

I get where you are coming from. However, this was a major time sink for our team on an enterprise app. Clients, in our case, want the same look and feel on all platforms. They don't always understand why this is difficult.

Both would be nice if there is no additional complexities or performance overhead?

Your clients sound like those MBA-type idiots who demand what they want because they think they are "business" experts. When their awful ideas blow up in their faces, they whine like babies and you for letting them do it. I now understand why Apple avoids directly marketing to the business market.

[Joebeazelman]

Achieving native look can be done with themes. No need to complicate whole MAUI architecture just to render differently looking controls on different platforms.

To make a good UI/UX usually means going beyond using just native controls. Specific requirements often need custom controls. However, to make a custom control in Xamarin.Forms developer needs to know three frameworks (XF, native Android, native iOS) instead of just one. And differences in architectures quickly turn simple tasks into complex problems.

Using framework based on native controls drives development costs much higher than using framework with unified rendering architecture.

No it can't! Look and feel is a complex issue which is why so many cross-platform products get it wrong. There are lots of nuances end users pick up on. If you don't care about them, then just give them an HTML based app.

[Mrxx99]

It sounds like the best solution would be to support both and the developer can choose

[davidortinau]

I would say the solution we are targeting is supporting the spectrum between purely native and uniform. We will continue to work throughout the development of .NET MAUI to fill out the features needed to deliver apps easily anywhere you wish on that spectrum.

[JohnH-FF]

I would prefer they fix existing issues rather than split development efforts. I am all for MAUI, as long as they resolve the basic, fundamental problems that XF has. This is a good time to introduce breaking changes to course correct the platform.

[Depechie]

Just for reference @JohnH-FF a lot of companies want their 'branding' be known everywhere, hence the same look and feel on each platform ( look at the Facebook app or other major brands ). So this is actually a high valued request to have easy same design parity on each platform.
And yes, I agree the other side should also be available, having native look and feel per platform.

@Clancey showed his SKIA proposal yesterday during the MAUI overview Twitch stream, so if they decide to add it in the main repo, this would be awesome!

[JohnH-FF]

@Depechie Branding, absolutely. Icons, fonts, colours. Buttons though? What a user expects and what a company think they want are not always the same.

[dhindrik]

I like it when it keeps the native UI look. And if you want identical UI you can achieve it with Visual. Visual will probably be part of MAUI and it will be good if more visuals are added. But Visual is also a great way for third-parties to add "themes" to Xamarin.Forms/MAUI.

[GalaxiaGuy]

I realise this is descending into sharing anecdotes, but here is my experience:

• Just myself, I would prefer a native look and feel. I personally know a lot people (who tend to also be into technology) who feel the same way.
• Designers I work with tend to prefer consistency.
• I work for an agency, and our clients either want consistency, or don't care (i.e. they want the easiest and/or cheapest).
• Most users I know who aren't into technology, don't care and barely notice when an app is doing something more fitting for a different platform.

As a developer paid to build apps for others, I'd have to lean towards consistent cross platform controls.

[Joebeazelman]

Thank god there's a developer out there who gets it.

If developers don't care about native look and feel, simply do not bother using a desktop-based development framework. There are hundreds of HTML/CSS/JS tools, including electron, for building apps that look the same across platforms. If Microsoft decides to take the path of least resistance by creating a write-once suck everywhere solution, then it should cancel MAUI now. There are already too many such products in the marketplace.

[AppFzx]

As a dev with a lot of years experience, I’m here reading this trying to decide whether to attend any Maui sessions at Live!360.
Users expect an experience sufficiently consistent with the platform they use to keep them from noticing confusing differences. If a user wants to see historic bank statements, they don’t want your ‘clever’ new date-picker, they want the familiar one that their thumb’s muscle memory knows how to operate on their phone. You’re not being clever or saving time by making an inconsistent experience, you’re being an {redacted}hat and you’re driving customers to competitor platforms. But by all means, if you’re in the habit of making UI’s “consistent” across platforms, please continue! I only get hired when companies get tired of the effects of zero effort development/developers/designers. I won’t work for a client that doesn’t care about the end customer and if you’re a developer with any self respect, you shouldn’t either. If Maui doesn’t make delivering native looky-feely easier, it’s complete trash.

[aguywithcode]

It looks like MAUI is bring back Templated Controls and raw visual elements. From WPF. I'm still browsing around but I saw a reference to Themes as well so best of both worlds...custom look and feel for those who want it. Platform specific themes who want that.

[TheRusstler]

I hope to make a real-world case for the "identical ui on all platforms" view:

• My experience in the business world is a strong customer desire for apps to look identical on all platforms.
• Our customers wish to choose hardware purely on it's physical merits, not its influence over the the app's design and UI controls.
• Our designers want to draw a beautiful creation, imagining everything down to the pixel, not "make it look and feel like every other [android|windows|ios] app out there".
• A consistent UI has huge benefits in terms of training - if a person is experienced with an app on one platform, they would like (and expect) it to look and feel identical on another platform when switching for personal, or company-imposed change.
• This view applies not just to business apps, but in the consumer world as well. As @Depechie mentioned, apps like facebook, whatsapp, messenger etc. all try to make the experience the same across platforms for simplicity and to conform to their branding and design.

Historically we have lived in a divide of Apple vs Google vs Microsoft user loyalty, whereby individuals want all apps to follow the specific style of their preferred company.

I feel the future lies not in greater divide, but in a focus on designing the best user experience as the designer imagined it, pixel-perfect down to the user's preferred physical device.

[Joebeazelman]

You shouldn't be writing a desktop application if you're not interested in giving your customers a first-class user experience. Write your application for the web:

1. Business people (MBAs) are ignorant, slow, and stupid, yet they think they're smarter than everyone. I have very little respect for these vermin and their ignorant ideas regarding technology. Listen to these people at your own peril.
2. "Based purely on its physical merits?" You clearly don't understand the mobile or desktop market, or your customers are dishonest. Android users are envious of iOS users and will claim it doesn't matter what OS anyone's using. Apple is clearly a superior product. Revenues in the $100B/qtr revenue prove it!
3. Your graphic designers are not User Interface designers! They don't know the tiny and incredibly complex nuances in user behavior. Applications are about usability, not about shouting your corporate brand at the user. Again, make a website!
4. So, you want to give the user a sucky experience so that you can save money on training? Priorities? iOS users want an application to look and behave like an iOS app. They paid for the experience and if you don't give it to them, they'll select a competitor who will. If you really want to make your job easy, focus exclusively on iOS because iOS users are not about to migrate over to Android anytime in the distant future.
5. Those apps are not real desktop apps. They're all single-page web applications Again, go build single-page web applications.

[GiampaoloGabba]

Maybe i'm missing something, but now i'm already able to get the same look and feel on ios and android just using styles (with or without material theme) & some platform effect.

I like to have a general look and feel of the app wich is almost the same, then there are the "functional" details wich are specific to the platform: like the app bar if i choose the native one, the native dialogs & pickers. But thats fine because that are small functional parts that use the OS pradigms that users are used to.

Btw with all the new things that are coming (appbar, tabview, path, shapes, shadows) the process to streamline the look and feel will be easier.

Moreover, with the new acritecture it will be much easier to create and integrate custom control with skia! i'm sure that a lot of third party control will raise if the community will needs them :)

[legistek]

It looks like MAUI is bring back Templated Controls and raw visual elements. From WPF. I'm still browsing around but I saw a reference to Themes as well so best of both worlds...custom look and feel for those who want it. Platform specific themes who want that.

Don't read too much into that. So far MAUI is almost a complete copy of Xamarin Forms and IControlTemplated has long (always?) been a part of XF but isn't for templated controls the way we think of them in WPF.

That said I agree I would like to have the option of lookless/templated controls.

[billhenn]

Coming from a WPF/Silverlight/UWP background, it would be very valuable to support WPF-like ControlTemplates along with content DataTemplates. Those mechanisms make it so easy to customize UI rendering.

[bkaankose]

I want to look at this discrimination from different angle.

The root reason why business wants every page/control to look same is they are not aware of design guidelines for each platform and they think having 1 consistent UI will cost them a lot less than adjusting/supporting every visual element for different platforms. This is wrong and it is not Xamarin's or MAUI's job to fix.

Coming from Xamarin and UWP background, I personally prefer to have native feel for each platform. However, I also expect that button I put on the view must be treated well by the framework (Xamarin or MAUI in this case) that I should not create extra margins, different renderer-like classes to support to fix this layout issues. I put it there, it is native, it's not identical between platforms but it is similar as highly it can get in terms of layout, it is not rendered by Skia, it has all the effects/shadows that native platform provides, it respects the OS version I am in and it does position itself well with other controls or UI containers I put into. This may seem a lot, but this is something I observe from the Xamarin's history. They tried to achieve this and came a long way. Thrust me, you were not able to just create a single basic page and make it perfectly layout in different platforms 4-5 years ago.

Personally, their biggest mistake was to support both stupid business ideas and develop new features as the framework develops. They forced themselves too much behind this 'supporting business by making platform highly customizable in order to lower development effort' idea, that eventually made the platform lose in the competition. And this lose was caused by the nature of Xamarin Forms. This nature relies highly on the platform specific and nature feeling of controls. You can't deny this fact of the framework by saying "Here you go all the redundant stuff that is highly against our platform's core nature we wasted team effort on instead of strengthening our framework core that can be super efficient for the developers that know what they are doing". :)

Other platforms that powered by graphics libraries are not good candidates for this approach. Because they intended to be "Same feeling on all platforms" approach. But Xamarin or MAUI is not, and should not because it is not an efficient way to support 'design and develop' approach.

TLDR; the problem is not the framework itself, it is the business and no framework should change it's core for the sake of supporting stupid business ideas...

[legistek]

TDLR; the problem is not the framework itself, it is the business and no framework should change it's core for the sake of supporting stupid business ideas...

LOL. The essence of what's wrong with so many developers. You think the business and the users should adapt to you and not the other way around.

Maybe you haven't noticed but the overwhelming majority of apps are WEB FIRST now and when they do have native versions they go out of their way to make the native version look and feel just like the web version. This is thanks to React Native and Ionic, etc., that allow you to use the same markup and code in every platform. That's why React Native and Ionic have been dominating while XF - not to mention any native app platform including Android/Java and iOS/Swift - have been falling behind HTML/Javascript.

Businesses WANT uniformity for brand recognition, consistency, and user familiarity. You get the same experience from the application no matter what device you're on. That's what modern users expect. Point me to a major modern application that looks substantially different between web v. iOS v. Android v. Windows. Facebook? Netflix? Slack? Microsoft Office? Nope. nope, nope, and nope.

Native mobile apps in general are becoming irrelevant now too. The only native platforms I actually care about are Windows and MacOS and I want my app to look identical between them. I'd like to be able to use the same codebase for web too but if I have to have a separate one, then I'll make it mobile friendly and publish it to iOS and Android as a PWA or use React Native. Users don't know or care about the difference between a native app and PWA.

Bottom line is yes my "stupid business" requirements dictate a uniform experience and maximal sharing of designs and code across platforms.

[Joebeazelman]

You are completely talking out of your rear! You have no knowledge of the effort it takes to produce a high-quality user interface. Good developers don't design UI, they follow the UI design guidelines set by Microsoft, Google, or Apple.

[PureWeen]

Just to get this straight, that means that MAUI Elements in combination with the "thing to be defined" can be used to create a UI that looks the same for all platforms? Similar to how Visual=Material does it currently in XF?

Remove the word MAUI from your sentence and then yes!

I want to clarify a bit that this isn't a Maui thing this is a by the end of the year as part of Forms thing. All of the features I'm talking about are on the XF roadmap https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap

We're still figuring out the best way to expose this idea out. Whether it should be through a Visual or adding ControlsTemplates to everything.

Adding ControlTemplates to everything is a bit weird because then what about native controls?

We have a spec here about ways we want to customize visuals
xamarin/Xamarin.Forms#5005

A neat idea @jsuarezruiz had is that we could introduce a VisualTemplate that would be specific to the visual you specify.

So users could possibly do something like this

<Button>
<VisualTemplate>
<ButtonControlTemplate>
<grid><label></grid>
</ButtonControlTemplate>
</VisualTemplate>
</Button>

[kevinjpetersen]

@PureWeen The downside and bad part of the example at the bottom (in my opinion) is that users have to write alot more code. I personally think if there's a way to make controls just a single liner, that would make the process of developing apps ALOT faster, while also being streamlined.

If you mean that the syntax is for making the actual Controls for the Visual= thing, then that could probably work yes, but for the users that just want to "Create Project" and then just start coding in XAML, they shouldn't have to type the above, simply to make controls look the same on each platform :)

IMO :)

[PureWeen]

@kevinjpetersen right!

All I'm articulating is how users would customize. Visual propagates through your entire hierarchy so you can set a Page to

Page Visual="MakeItAllTheSamePlease"

At which point all your controls will just use the visual setup for that which renderers the controls using xplat elements

BUT I also want to emphasize this isn't something we're directly promising yet :-) If we're actually going to build all these controls.

We'll start with appbar/tabview and then probably start building out from there.

And then once we have the mechanisms for building these controls we'll take any PRs from people that want to create the symmetrical xplat controls.

So the main thing I'm wanting to know from everyone. What are the limitations of these specs https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap

Where do they fall short of achieving the points brought up on this issue?

[legistek]

We're still figuring out the best way to expose this idea out. Whether it should be through a Visual or adding ControlsTemplates to everything. Adding ControlTemplates to everything is a bit weird because then what about native controls?

Agreed not everything would be derived from Control. That's why I was suggesting a whole new System.Maui.Presentation namespace mapped to http://schemas.microsoft.com/winfx/2006/xaml/presentation that uses the WPF/UWP naming conventions, for everything from ContentControl to ItemsControl to ButtonBase, etc. If you want to go ALL templated, like I would, you say xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation". If you want to go ALL native, you say xmlns="http://xamarin.com/schemas/2014/forms". If you want to mix and match, you can do so through ns prefixes. Either way there's a clear distinction between controls that will use native rendering and those with templated rendering and you can pick and choose. System.Maui.Button would be drawn by the native renderer but System.Maui.Presentation.Controls.Button would be templated, with naming conflicts avoided via the ns's.

I'm not sure I see the value in a special template for each control? At minimum we would need to be able to make our own so the base for ButtonControlTemplate needs to not have internal constructors and such that prevent us from subclassing. As an avid WPF/UWP fan though I would of course urge you to stick with ControlTemplate qualified with a TargetType for validation purposes.

Where do they fall short of achieving the points brought up on this issue?

This (xamarin/Xamarin.Forms#6452) is definitely a blocker right now because it prevents doing this "xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation".

There are also issues with IControlTemplated being internal and the way TemplatedParent binding works, which I tried to fix when I implemented RelativeSource binding but part of it had to be undone for compatibility. Essentially it's impossible now to use ControlTemplates with anything other than a ContentView. If we just added Control to XF Core - with all the relevant templatable properties like Background, Foreground, etc., and had it implement IControlTemplated that would work.

Finally input events, bubbling, and coordinate transformation, as well as matrix-based transformations and animations, need to be added in at the framework level so a spec is needed for that. I assume we want the platform to just do the bare compositing of primitives without necessarily having to be aware of the visual tree, and provide low level screen/mouse input events to the framework, letting the framework do the routing.

Otherwise I think it's just a matter of writing the renderers for the primitives and settling on what they will be.

All my contributions to the XF repo have really been with this eventual goal in mind so please I'm very willing and happy to help further to steer it this direction if that's where it's going.

[legistek]

@PureWeen The downside and bad part of the example at the bottom (in my opinion) is that users have to write alot more code. I personally think if there's a way to make controls just a single liner, that would make the process of developing apps ALOT faster, while also being streamlined.

If you mean that the syntax is for making the actual Controls for the Visual= thing, then that could probably work yes, but for the users that just want to "Create Project" and then just start coding in XAML, they shouldn't have to type the above, simply to make controls look the same on each platform :)

IMO :)

I was assuming from the example that ButtonControlTemplate could be a StaticResource so you could just say:
<Button VisualTemplate="{StaticResource MyButtonTemplate}"/>

Furthermore I would assume/hope this could be incorporated into a Style which you could set a default for in a resource dictionary.

Basically I just hope/want it to be cross-platform WPF. Ok? I proudly admit it. :D

[PureWeen]

I was assuming from the example that ButtonControlTemplate could be a StaticResource so you could just say:

Furthermore I would assume/hope this could be incorporated into a Style which you could set a default for in a resource dictionary.

Yes

Basically I just hope/want it to be cross-platform WPF. Ok? I proudly admit it. :D

Hehe.. I'm a really big fan of WPF control templates. Anytime I have to customize a control natively UWP is typically the least headache.

I'm hoping we can bring a lot of that ease to the table with our current road map!!

[GiampaoloGabba]

There are a lot of useful informations in this thread, i love it :)
The only thing that worries me a bit are performance.
If we can customize all the control with an hypothetical Visual="Whatever", that replaces all the native control with custom ones created from MAUI elements... well, potentially there may be many more native views added to the visual tree, resulting in a lot of layout measurements, wich are killing performance on mid/low-end android phones.

[davidortinau]

Yup, that's a concern to watch out for. Thing is, we see developers doing this today all the time and they seem very happy with it.

In cases where the perf is unacceptable, perhaps SkiaSharp is the best option.

[FruitTreeAlchemist]

I must agree this was a major time sink to get our enterprise app to look the same on both IOS and Android. In our case, the clients want the same look and feel across the board.

[njsokalski]

I am a UWP developer, and therefore in the process of learning and converting my apps for Android, iOS, and probably at some point WinUI. While attempting to learn & use Xamarin one of my biggest frustrations has been a consistent UI (regardless of claims, shared code does not always look the same, so I felt like I was just writing 99% of the apps separately anyway). What I would like to see is markup that can detect the platform or use a specific one. For example, a button might have the following elements available:
WinButton (a Windows-style button)
DroidButton (an Android-style button)
iOSButton (an iOS-style button)
Button (this would automatically detect the platform)
A page (or whatever the root XML element ends up being called) or the entire app might also have an optional attribute or property specifying an OS style (so that, for example, a developer can say Button and have it be the same style on all OS's using the familiar and shorter name).

[butaixianran]

I can't believe people are still discussing this.

Having the exactly same ui on every platform is the reason why flutter is popular.

Not having the same ui on all device is why XF is not popular.

flutter is killing XF. If this new solution won't have same ui on every device, then flutter will kill this one too.

This is the basic need of cross platform. If you offer different UI, then you are not fully cross platform.

If this is still under discussion, then this solution is already halfway dead.

[JohnH-FF]

So you never meet anyone have 2 phones.

Sure I have!
Is it the majority? No.

Users don't care if the app is exactly the same on iOS and Android. Most are using a specific OS, few have both. Are you saying the needs of the few out way the many? Where is the logic in that?

I don't understand why you are getting so heated about this. MS has already stated that we'll be able to choose. We choose for our apps to look like native apps on each platform.

[saint4eva]

Are you a mobile developer?

It's not just about mobile. Flutter is targeting on Desktop apps now.
check this: https://flutter.dev/desktop

Flutter is based on Dart. And dart is google's dotnet, it can create app on every platform. Now flutter can do this too. Which means dotNet and even QT for c++ can be replaced by flutter in the future.

Cross platform uniform UI is a must have thing. And Xamarin is kind of stupid didn't offer something like flutter.

If that makes you happy, you can use it.

[butaixianran]

People are using it. Not just on Desktop, some big internet companies are using dart on server side and are very happy with the result. They are sharing their experience to us.

[saint4eva]

And some big companies are not using .NET, C# and Xamarin? And even C# on server?

[butaixianran]

Well, most companies don't use C# at all. For server side, Java is for old companies, almost every new companies choose Golang. There are some small projects are still using nodejs for server side. But most of them are being replaced with Golang.

Now, some mobile app teams are trying Dart on server side, so they only need one OOP language for both server side and client side.

So, where is C#? I can't see any company is still using it. Well, Unity for game is another topic.

[Clancey]

We want to allow both Native UI Elements, and Identical UI on all platforms. As well as a hybrid that is a mix of both. At the end of the day the developer should have the choice to choose how the toolkit looks and behaves. Even at the control level.

[GiantappMan]

I have experienced Flutter for windows, and the experience is good. I wish MAUI is a thing just like C#/Xaml version of Flutter. Otherwise, I think I might give up using c# to develop UI.

[saint4eva]

And what is flutter exactly? Isn't it about using code to write UI?

[GiantappMan]

No, I prefer to write UI in XAML, but keep UI rendering consistent across platforms, just like Flutter. This is the only attraction for me, XAML writing and consistent rendering.

But if MAUI can't keep the UI consistent, just like xamarin, I might prefer to use Flutter.

[giuseppenovielli]

I think that, the most interesting .NET MAUI's feature will became that developers can be choose if use Native's UI or Draw's UI component.

With Native's components, thanks to Xamarin.Android and Xamarin.iOS, we have 100% or less (iOS Swift) native API, and access to native UI, for example new iOS 14 picker, immediately, and i thinks also at iOS Gestures, that are different from Android

With Draw's component we have a more faster UI, Customized, and i thinks with less BUGS, why logic is written by Microsoft and not by Apple or Google, using Skia, but also native Graphics API....

So developers can choose if use Draw component or Native UI.

[AliShahesmaeili]

Look at this

When we define the buttons, if we do not set style it, it will display by default in any operating system with the same default style.
<button />

Now, if we want all styles in all operating systems to be the same style, use the following method:
<button Style={some styleForAllPlatform}/>

If we want to have a separate style for each control in each operating system, this way:
<button AndroidStyle={style} IOSStyle={style} WindowStyle={style}/>

And in Visual Studio in the design section be an option to show us the UI output in each operating system

[Xyncgas]

Let's not forget there is already a unified UI called browser, which is available via BlazorWebView, if you are gonna build a custom styling process to draw abstract UI that's unified accross platform you are sabotaging the browser basically, although it would be impressive because instead of relying on the browser imagine you can use css for drawing your UI and it gets turned into native platform codes it must be good for performance, but if microsoft is not intending to kill the web by making MAUI into a browser that runs .NET instead of javascript, then what they are doing right now with [GraphicsControls] https://github.com/dotnet/GraphicsControls) is something far from doing unified custom UI

[Xyncgas]

Sure you can use their library just like we always have with xamarin, but that's all you get, you get the same check box across platform because you get to set the border width the color etc but you will never have the ability to customize anything for once and for all platform by using what they provided for you, you still have to do it yourself, then you want to make it easier, and you make a library, and it's not going to be a library that provides different components that will look the same but to provide the ability to style an element however you want and it will look the same across platform