> Most people don't realize how many apps written in Flutter they use daily, simply because it's impossible to tell
You can't be serious. Maybe on Android, but on other platforms—especially iOS—they stick out like a sore thumb.
A number of them just look like Material Design Android apps awkwardly transplanted over, but I know that's down to the developer so I won't hold that against Flutter. But scrolling through the Flutter showcase[0] and calling those apps up to look at screenshots on the App Store—none of them look like native iOS apps. They don't look bad (mostly), but they don't fit in.
Don't get me wrong, I don't expect anyone else to care or even notice. But for those of us that do care, you can absolutely tell.
Sure, but not every cross-platform app developer wants their app to look "native to iOS". Especially if you want your app to look the same on all platforms and/or have some creative design.
I can appreciate that as a developer, but as a user I don’t particularly care that some company wants to ship identical looking apps on every device under the sun.
I would prefer the apps I use to work and behave in a consistent way, using the same platform idioms I am used to. The software available and how it works was a large part of the reason I chose the platform I did.
Of course, I recognise that, a. most people just don’t care about platform idioms, and b. the choice is often a non-native app or no app at all.
Pretty sure most large succesful apps have their own UI and UI design teams. Cant remember the last time i saw anything cupertino in an app. Even Apples own 'Home' app only loosely use cupertino. Id say the most noticable effect is the bottom modal sheet slide up effect. on ios the original screen animates into the background a little bit. Apps that dont implement this can be spotted but thats not unique to flutter at all and flutter even offers a pretty good cupertino scaffold package that does this animation.
"cupertino" is the name of a Flutter widget set, not of the native platform controls or L&F.
Few Flutter apps are going to use cupertino because the whole goal of using Flutter is to create cross platform codebases to save development effort. To use an alternative widget set per platform is a huge amount of additional work, and having a cupertino app running on Android is even more of a sore thumb than a material app on iOS.
The two things that stick out the most to me are navigation behavior and text fields. Cross platform frameworks seldom get either right, with react native being particularly bad on the navigation front.
There are variances between Apple’s apps but they’re all using some combination of UIKit and SwiftUI regardless which limits how “wrong” they can be.
You’re completely right, but that doesn’t change the fact that I think it’s a bad idea. For a company that used to care so much about user experience, Apple has been throwing a lot of it out the window in recent years.
Only on HN do I hear anyone talking about platform native controls versus unified UI across devices. I have not once heard of such a complaint in the real world and indeed, I have more often heard users wanting a unified UI over one that changes with each platform, simply because these days we have multiple devices where we expect apps to work the same.
You have to listen to the details, like "where is the back button", "Why does text work differently". There are some people that understand that it is different from the standard, but most just get annoyed. The discussion here is from a technical perspective why it is better, conformity of the app on different platforms vs standard behavior between different apps. There are very few people that care about the technical reasons why, but when you talk about the annoyances it is easier.
I'd also like to meet all these mythical users that have devices from every platform and want all their apps to look the same across all platforms. 99% of people I know IRL are in one ecosystem, with the exception of some that have an iPhone/iPad + Windows PC
In a previous company when we were looking at precisely this problem, building out multiple platform support, we did UX studies where this question in particular came up. The vast majority of people said they wanted apps to act consistently across devices. Most people on the planet use Windows with Android, statistically speaking, which are not similar devices at all, at least on Apple platforms you can use Swift for desktop and phone but not so for Windows and Android, so you have to make a choice at that point.
> The vast majority of people said they wanted apps to act consistently across devices
You shouldn’t trust what users say they want. It many times doesn’t correlate with what they want. Certainly, I would try and figure out what they mean with “act consistently”. My suspicion (for which I have zero evidence) is that they’re more talking about high-level similarity than about nitty-gritty details such as how many milliseconds to hold your finger down to select and edit text, how scrolling works, etc.
Also, I suspect they want devices to act constantly across apps, too: copy-paste should work, text editing should behave identically, sharing controls should be the same, etc.
In the current world (and, I think, in any world where there is competition in any form between platforms), they cannot get both, so then, it boils down to what is more important.
For me, that’s platform consistency. For example, I find it easier to get used to text editing being different on a phone and on a laptop than to get used to a zillion minor inconveniences/annoyances in typing and editing behavior between apps.
I also find it less of a problem if text and emoji look slightly different on a different device than when they look slightly different between apps.
If you have zero evidence against the mountains of evidence I do have, why should I be convinced of your argument. It seems like it is you who are talking subjectively about what you want and then applying that to everyone else.
I find it very hard to believe that majority of people prefer app consistency over platform consistency.
One example, I'm pretty sure there are thousands more: Why does every UI detail, except the logo, of Spotify looks and feels different in Android, Android Auto and PC/laptop? Because Spotify did not study what the market wants?
Spotify looks much similar between devices than it does to any specific platform. Does it use Material on Android and Fluent on Windows? No, it uses the same sort of styling on both. Don't mistake UI changes for screen size responsiveness, for actual platform specific nativity.
> The vast majority of people said they wanted apps to act consistently across devices
... which you can absolutely do while using native UI controls. "Act consistently" (UI controls are in similar places and present themselves with similar UX) is not the same as "look consistently" (UI controls are drawn using whatever system theme or drawing style is in use).
Certainly there is some overlap between look & act: a platform-native "dropdown menu" looks and acts a little differently on Windows vs Android vs iOS. But I think these differences are not in the majority, and when users say they want apps to "act consistently" across platforms, you an absolutely achieve that with native UI controls, and it's not even that difficult.
This is a big problem I've run into when doing user studies myself: you need to be very precise with your language when asking users questions, and even then you often need to dig in and ask for details about what they mean by their answer. And of course having visual examples and functional mockups for users to play with helps a ton.
Another problem is the leading nature of questions you might ask during a user study: if you simply say "do you think it's better if the app acts consistently across platforms", of course users are going to say "yes". Saying "no" to that question feels kinda stupid, TBH. But if you were to give a user an iPhone and Android phone, with the same app, using native controls on both platforms, and ask them if you believe that the apps "act consistently" with each other, users are probably going to say "yes", as long as the design and UX of the apps in general are consistent with each other.
(And even that's a contrived test: very few people use both an iPhone and Android phone regularly!)
You can achieve them with native controls but only at the bottom-most layer, if you actually want consistency. Spotify for example does not use Material on Android, Human Design Guidelines on Apple, and Fluent on Windows (well, they use Electron, bypassing native desktop entirely), they use their own custom controls that may at the very bottom layer be based on native text inputs, but they rebuilt all the actual UI stuff from scratch to achieve a unified look and act.
This is all well and good but the people I see on HN are ones that say that the app should actually look native on each platform, ie Material on Android etc. This opinion is what I'm pushing back on, not the fact that ctrl + C works on Windows and CMD + C works on Mac.
Of course, this is the reason why cross platform frameworks are so popular, if you're already gonna have to rewrite the UI for every platform, why not just do it once and save yourself the effort? After all, users won't care, as they've shown, because they care much more about new features coming out. There are always tradeoffs because time is finite.
> This is a big problem I've run into when doing user studies myself
Sigh, do you really think that all of these weren't considered when we did user studies? This is like 101 material, frankly almost insulting to imply that we didn't, therefore it can justify your priors, even though I agree with your points to some extent as said before.
It's not the end users that care about the uniformity but the fact the corporate design team wants there to be uniformity across all their platforms they support. This is part of branding and user experience. I'm not arguing for or against, just stating that is where the push for this comes from. It would make support, for example, easier, if all versions of your app user experience were similar.
This is very true, and it's a PITA when the corporate design team doesn't know anything about mobile design and thinks mobile apps are just "Honey, I shrunk the web app" with some Figma plugins to help. It can be an uphill battle to get them to compromise.
It's because while it's true on the company side, this comment is making it seem as if the company is doing this against their users' will, while in reality, most users genuinely want a unified experience across platforms for their apps, as seen by some of the comments here.
It doesn't seem to mention it being done against anyone's will. It's definitely true that a company can save money by only needing to maintain one set of help instruction screenshots, for example.
Ever since the release of the M1, the number of Android users who now use Macbooks as their laptop has sharply increased. Even moreso for work purposes.
Hello! I use three platforms on a daily basis. I vastly prefer my apps to be reasonably consistent with themselves rather than trying too hard to adhere to the platform.
My wife is on two. Most of my friends are on either two or three. In fact, I'm pretty sure my parents and a few coworkers are the only people I know who are exclusively on one platform.
Many (most?) people don't have a clue as to what the particulars of any given platform even are. They know how to get around in each app they use, and maybe the web browser, and that's it. Lots of gestures go completely unused.
> I'd also like to meet all these mythical users that have devices from every platform and want all their apps to look the same across all platforms.
It's not even a single person that has them, but I think we have all had the experience of family or friends that need assistance with something but they have a different type of phone whose organization and workflow is completely different because it's native. You literally can't help in this scenario without having physical access to the device.
I've genuinely never heard of such annoyances from actual users (at least not from most users, who aren't power users, and even then, not even from the power users), and most cross platform frameworks already hook into the native APIs like for the back button, so it'd work the same either way.
Out of interest, do you know many seriously vision-impared people?
Windows, and Mac OS X in particular, have quite good support for accessibility if you use their built-in GUI systems, and unified UIs are often (not always, vscode and chrome are quite good, for example), very bad, sometimes just a black square as far as accessibility goes.
Many cross platform frameworks have good accessibility support, not sure what that has to do with native platforms, as the cross platform solutions simply hook into the native platform accessibility APIs anyway.
I didn't know flutter had such good support, and I'm very happy to hear about it!
Unfortunately, most cross-platform frameworks have awful accessibility support, I've looked at various in the past and just found failure after failure. I am now going to look harder at flutter.
People have multiple devices, sure, but in my experience (among non-HN people) it's iPhone+iPad or iPhone+mac dominating, with a decent contingent of iPhone+Windows, and rarely Android+Windows. (This is of course US-centric; the iPhone is more popular as a mobile platform, and that often entices people to buy into other aspects of the Apple ecosystem.)
It is exceedingly rare for the multiple devices to span the UI toolkits of more than one or two company-platform. For people in the Apple ecosystem, they don't want to see something that looks like it belongs on Android.
Regardless, "unified UI" doesn't mean it can't use native controls. More important from a UX perspective is that controls are in the same places and behave similarly, and that the app is organized in a similar manner, plus or minus what might naturally change because of differences in screen size and input method. And that's another useful point to make too: mobile, tablet, and desktop experiences are often quite different, and that's normal and expected at this point.
Another consideration: it's a lot more difficult to make an accessible app when you draw your own custom UI controls with your own custom behavior. If you use the native UI controls, you get a lot of the accessibility features for free, and have to do much less work to make sure everything works for people who are vision or mobility impaired. From what I understand after reading about blind people's experiences on various platforms, most companies that do custom UI don't bother, and the accessibility of their apps is atrocious.
I think you made the same points twice so refer to my other reply regarding your first few paragraphs.
> For people in the Apple ecosystem, they don't want to see something that looks like it belongs on Android.
I have not seen evidence among normal people that this is true, given that the most popular apps all have custom UIs that don't necessarily follow Apple's HIG, TikTok for example. Regardless, the point is that if you're making an app for every platform like iOS, Android, Windows etc, you must make a choice lest you exclude all non-Apple users for example. ByteDance does therefore indeed use Flutter, based on this (at least in some capacity).
> mobile, tablet, and desktop experiences are often quite different
Don't conflate unified UI to mean non responsiveness. Look at Spotify, their UI is essentially the same in design except it is responsive among mobile, tablet and desktop, all while not looking native at all on any of them.
Regarding accessibility, many frameworks can be robust in that simply because they hook into the native implementation anyway, so I'm not sure where this trope of not having accessibility comes from. Here is Flutter's for example, with a dev in this thread also having talked about how they have one of the most robust implementations of accessibility that they have found among any framework: https://docs.flutter.dev/ui/accessibility-and-internationali...
I think the problem with the same app following native app idioms is that now the support and instructions behind that app will have to be different on every platform.
E.g., if you have Instagram on your iPhone, an Android user won’t be able to tell you “just click on this, this, then this to change your XYZ setting” because it will be in a different place than the Android app if developers follow native conventions 100% of the time.
The fact that Spotify or Instagram or any of those other platform-agnostic apps look and function the same on every platform is a huge benefit to practical usability.
I think the only time when nativeness matters is when you have an app that’s doing stuff that’s closer to being “low level” to operating system features. For example, an app that performs file system management, I don’t want that to have the exact same UI on Mac, Windows, and Linux, because those platforms have different conventions for where things go and how files are represented.
> I would prefer the apps I use to work and behave in a consistent way, using the same platform idioms I am used to. The software available and how it works was a large part of the reason I chose the platform I did.
There are DOZENS of us!!!
I try my absolute best to find apps that use the native Apple language, both design and code. I can't stand these framework apps. I will Pepsi challenge this with anyone who asks, I can smell a framework app.
> I will Pepsi challenge this with anyone who asks, I can smell a framework app.
The platforms ship with things like keyboard shortcuts for navigation and text entry, minimal accessibility features like screen reading of text and navigation, common idioms like drag and drop and the clipboard - none of which are typically handled by cross-platform widget frameworks by default.
Only gigantic projects like Chrome and VS Code will take on the effort of (partially) reimplementing these in their codebases to match platform behavior.
Do you only use Apple devices? That may be why, because statistically most of the world's population uses Windows and Android where there really isn't a concept of "native" because they each have a few different UI frameworks.
Do you hear people complain that __websites__ have different aesthetics?
I used to share your opinion but since the web I think it is great that designers can have original designs and I started to worry about more important things.
I agree. What doesn't get enough attention in these often dogmatic debates is that there are some native conventions that are hugely important for usability while others are mostly irrelevant.
E.g, I have to use a Java app on the Mac that uses Ctrl+V rather than Cmd+V for paste as well as other Windows/Linux keyboard conventions. This is extremely jarring.
Web apps never do that. Browsers are pretty good at using native conventions where it matters by default. Of course web devs sometimes go out of their way to vandalise the browser's perfectly good defaults - e.g. by overriding scrolling behaviour.
Surprisingly, some of Apple's own native apps (such as Numbers) break platform conventions in ways that makes the app extremely inconvenient to use.
The web is interesting because we never had rich components provided by the browser to begin with. Web applications have always had to draw everything but the most basic inputs themselves, and the design of web apps has evolved accordingly.
In an alternate universe, where web apps were embraced by the platform from the start rather than something people had to shoehorn into a document sharing mechanism, and we had rich components built-in, then yes I would probably be annoyed if people insisted on rolling their own versions. After all, I am annoyed when people use a span with a click handler instead of a proper anchor tag, because it usually breaks middle clicking or opening a link in a new tab—a platform convention I have internalised and expect to work.
Note this only applies to web apps, not sites. Much like how I do not have any problem that magazines don’t share a common layout.
> Of course, I recognise that, a. most people just don’t care about platform idioms
This is the big one. HN commenters are not representative of the average user. You'd have to specifically point out the differences for them to even notice, and even then they simply don't care.
Casual users do care about app behaving wrong, though.
If you can't copy or paste things, or if the navigation is backwards, or if the calendar looks weird etc etc - it all causes some minor frustrations, when things don't behave as user wants them to behave.
They don't know what "native" means, obviously - they don't have that knowledge. They just know crappy apps from well-behaving apps, because they have a frame of reference (vendor-supplied native apps).
Is there a concrete example of this? I still only hear this on HN where some mythical user gets annoyed about copying and pasting (most apps don't allow that, even, like TikTok or Instagram, which are the apps where most users spend the most time). Like the sibling commenter, I only have seen whether the app does what they want or it doesn't, most don't notice any annoyances unless they're really looking for them, which they're not.
> I still only hear this on HN where some mythical user gets annoyed about copying and pasting
Perhaps they're not complaining because they've just accepted that it probably doesn't work and so don't even try anymore.
My SO has stopped trying to copy/pasting stuff, I now always just get screenshots, both from mobile and her PC.
At work, almost none of the customers I interact with copy/paste stuff, they send screenshots as well. Like, "can you send me the order number?" will result in a screenshot of the order number control, or often just the whole order window.
The trouble with this is most users only use one platform and so don't care. They just see the app as badly implemented as it does not match other apps on the platform.
What kind of users/apps are these? I'm genuinely curious about this, actually. I have a couple of apps with 100K+ installs, and I talk to people who are actual users from time to time. I have never ever heard the claim that they don't like UI because it doesn't feel native. Like ever. But I can imagine that in some niches/demographics/app types it might be different. Can you share some evidence or explain how you built the understanding that users dislike non-native UIs?
I've built apps with pretty high retention rate so even if they're annoyed, it doesn't seem like they really stop using them. Mostly though, based on user feedback we collected, not once have I heard anything about UI complaints. It really feels like this is a common refrain on HN about what HNers think happens in theory versus what actually happens in reality wrt user preferences.
Note, this has nothing to do with your app or this specific discussed GUI, but this is something I have noticed over time...
I think that what is commonly seen by devs as complaining and being overly concerned with details that don't matter is instead a some of the time advocacy for doing things the right way for the sake of it. It is totally possible to build things that meet the bare minimum requirements for user retention and for people to not complain, but that doesn't mean that it is optimal. You can build Soviet style housing blocks that people live in that are completely functional and that no one will have any problem with, but the quality of life is degraded as opposed to what could have been built.
It can be tough seeing through the grumpy nerd 'I want it my way because my way is best' and finding what is actually 'this is a good thing that we should be doing, and if we did there would be a marked improvement for everyone', but I would not forsake one due to the other.
It's more than there is no evidence of an issue, so why pretend that there is? The "right" way is entirely subjective, unless you can give me some objective criteria for what it should be.
The issue in this case is pretty plainly that the application does not subscribe to the conventions of its host UI. I'm sure there is no objective reason why we need to conform to any convention, except that there is one.
Then that is subjective too and not really worth caring about, because it comes down to a matter of taste. You like platform conventions, but most people we surveyed simply don't care, the fallacy of vocal minorities and all.
Perhaps so, as different cultures have different tastes anyway. That you don't like Soviet styles is no indication of whether people in the Union did or didn't like them.
Not all non-native-looking apps are badly implemented, but a huge number of apps that use cross-platform frameworks do so primarily as a means to cut costs because the goal is to make development as cheap as possible, and that shows in other aspects of these apps too. This creates an association between cheap/lazy apps and cross platform UI frameworks.
It’s kind of like the difference between VS Code and MS Teams. Same company, same underlying technology (Electron), but Code is good while Teams is awful because MS invests so much more in Code. Even so, Teams-type apps are what tends to come to mind when people think of Electron apps because those are so much more common.
You could not be further from the truth regarding the size of the Teams vs VS Code teams. Teams has multiple times more developers, it's not a problem of funding that makes it suck.
In those cases, those app developers aren't doing cross-platform development, but are just trying to dump their app in as many places as possible. In such a case, why not just make a PWA and call it a day? Don't need an app if you aren't going to go native, especially with most apps being either content readers or CRUD apps anyway.
In most cases, I personally rarely want an app, and I'll use a website unless they happen to have created a great native experience. And since most apps don't, I don't use them, and I don't have a lot of apps as a result.
That is exactly the reply I was hoping for. Because that brings us straight back to the native issue; users also expect the app to work in a way that is comfortable and known to them.
As an on-again off-again (currently off-again) cross-platform app developer, I always want my app to look like it fits in with the rest of the apps on whatever platform it's deployed to.
As a user, I hate it when some app developer thinks they're cute and wants to skin an app differently or draw their own ad-hoc widgets.
Developers who think that way have no clue what their users want. Most iOS users want a native experience, not something else. When I see an app that doesn't have that, I quickly lose interest. Having the app look the same on all platforms is a dumb idea to start with.
I noticed the SNCF Connect app for France's rail was using it in their showcase which explains why the scroll views are so weird and busted feeling. They still stutter on a new iPhone. As a native iOS developer I'm somewhat biased and a lot of people likely don't care but it still feels off to me even for apps that use a complete custom design. I hope they can optmise away those kind of issues more as it's IMO always better to have alternatives.
Side note: Is anyone using Flutter just for Android? I'm kind of tempted to try this as dealing with the Android build system and packaging is bit of a pain, despite Kotlin and Compose being quite nice.
You still have to deal with the Android build system, `flutter new` just generates initial config for it and all the other necessary metadata (and that config can change between versions - I ended up manually diffing the generated stuff against a new app every time I upgraded).
At some point I made the mistake of not touching the code for too long and upgrading Android Studio when suggested, and I was never able to (find the time needed to) get that app working again.
> but I know that's down to the developer so I won't hold that against Flutter.
That is absolutely an issue with Flutter, which throws away the underlying platform UX and draws to a canvas. It gives you relatively few tools to target "native look" controls for each platform without maintaining multiple UIs in parallel composed of entirely different widgets.
Typically people just make the app look and work the same in all platforms, like how you might expect a responsive web app to be like; no one is implementing Notion with a platform specific UI, for example, using Apple stuff on Apple devices or Windows stuff on Windows devices.
You may notice that the first reference is from java, and i bet js lifted it from there. They may have been aware of java because they lifted the name too.
That is good to hear and hopefully gets fixed. It has been some years now, but I did use flutter for some toy projects and liked using it - I am used to using ReactJS I found there was a lot of transitive knowledge coming from that background.
Ultimately what dissuaded me from pursuing it for any bigger projects is a lack of examples of great looking production apps with complex requirements. When I was looking, I was seeing a lot of CRUD apps - display a form, click an upload button, ect. This was probably 2018/2019 when I was taking a serious look at it.
All of that is to say: Quality app showcases do matter for whether or not devs will trust a solution enough to pull the trigger.
I don't know how to fix the showcase problem. With web apps, it's easy – just scan HTML, deduce what framework is used, and add it to your showcase list. With Flutter mobile/desktop apps it's not possible. And there are zero incentives for developers to send their apps for screenshots. You just ship the release and move on to the next tasks.
I also discovered Flutter in 2018, and it kind brought joy into UI programming for me. I rewrote all web apps I had with Flutter and published a bunch of mobile apps, but the coolest thing is that I routinely make apps for my own (or my team's) use.
For me, Flutter lowered the costs of UI app development so much that I could just spend a weekend making some neat, small, practical tool for my own needs. I really love making these "private" apps – no need to care about all corner cases for all users, no need to polish design for all screen sizes/font sizes. Don't even need to be released (TestFlight at max, if doing it for a team). It's just fun, and I wish more developers could have the same experience.
This is trivial for any team that provides a framework/platform and spends any amount of time engaged with their customers - you know who your prestige customers are and you show off examples of the products they have built with it. The state of the showcase is just reinforcing the points made by the OP.
> With web apps, it's easy – just scan HTML, deduce what framework is used, and add it to your showcase list. With Flutter mobile/desktop apps it's not possible.
I think they're referring to the extra frame of latency when scrolling on Android. But then again, I've literally never heard anyone complain about that, I honestly don't think anyone notices, I believe the GitHub issue had to use a slow motion camera to even capture the issue.
Sorry, but do you really develop your software as a professional engineer based on "I heard X from few people"? With all the bias and filtering your brain does for this kind of "metric"?
Do you not? Engineering is a tool for solving human problems. If humans don't have a problem, then there's nothing to solve. Engineering is not the end in itself but the means to an end.
A lot of users do care for fit and finish, but stick around with crappy UI because it’s not worth rage-quitting over.
They do move when better UI + same-ish functionality comes along.
The one sort-of exception to this is Enterprise Sales, where the people buying the software don’t always use it. But even there, corporate purchasers do get flak in annual reviews / feedback cycles for especially crappy enterprise software — so even there, especially crappy UI will catch up with you.
But the question is will they move from a Java UI to a native windows UI, all else being equal. What if the Java UI is better ? What if the Java application is better
I think you are correct, but I think your example is a bad one. Most people do not have a realistic (their employer will use it at work, it even occurs to them that they could use something else) alternative to MS Office so will use it whatever MS does.
I miss the days when applications had their own look and feel. If your idea of great design is identical rectangles to all the other apps, I guess Winforms solved that use case 20 years go.
It’s perfectly possible to still have a unique look and feel without completely forsaking all the platform affordances. You get a lot of stuff for free or very cheap building using the platform toolkits: stuff that people internalise and expect to work without even realising it. I think it’s a bad idea to throw that all away.
Just like a lot of the "web application packaged as mobile app" frameworks did in the past, except with ugly iOS styling that also completely mismatched the expected navigational patterns.
What's worse, there are new applications with custom look and feel that do the same navigational sins today
I think people might be talking past each other on this issue. If you are on one platform only, then yes having apps behave the same is nice for muscle memory. However, if you're using multiple devices and platforms, then I want Slack to work the same regardless of device, I don't want iOS native navigation on the iPhone and Windows native navigation on the laptop.
You can't be serious. Maybe on Android, but on other platforms—especially iOS—they stick out like a sore thumb.
A number of them just look like Material Design Android apps awkwardly transplanted over, but I know that's down to the developer so I won't hold that against Flutter. But scrolling through the Flutter showcase[0] and calling those apps up to look at screenshots on the App Store—none of them look like native iOS apps. They don't look bad (mostly), but they don't fit in.
Don't get me wrong, I don't expect anyone else to care or even notice. But for those of us that do care, you can absolutely tell.
[0] https://flutter.dev/showcase