[Klonoar]

Slant is putting it mild - you gotta start putting a disclosure in these kinds of comments or something. You were a WWDC scholarship recipient, interned at Apple, and seem to base your career on Apple tech.

You are not a typical user, you will notice things most ordinary people would never think to notice. The vast majority of apps on a phone aren't even kept open by a user long enough for it to matter.

I say this as someone who prefers native controls, has written/launched apps in ObjC/Swift/etc. There's increasingly little reason to bother with the stack.

[saagarjha]

> You were a WWDC scholarship recipient, interned at Apple, and seem to base your career on Apple tech.

I dabble in Android and Linux as well ;)

> You are not a typical user, you will notice things most ordinary people would never think to notice. The vast majority of apps on a phone aren't even kept open by a user long enough for it to matter.

Agree on both counts, but I like to think that users aren't completely clueless. There are certain things that they do feel acutely: animation physics that differ from the system's (particularly for things like scrolling), lag, choppiness, lack of proper accessibility support…

> There's increasingly little reason to bother with the stack.

I disagree with this (this isn't just an iOS thing, by the way: I would say the same for every other platform I've interacted with). It is almost certain to be the case that the team that wrote the platform libraries is smarter, better, and cared more than you did about the UI (there are some very notable exceptions, but I think it's very obvious when this is the case). Going with the native stack means lock-in and sometimes more work, but in exchange you get a significant amount of functionality "for free" (sometimes without even realizing that this functionality existed) and automatically share a common design language with the rest of the system, which is a usability plus for users almost all of the time.

[dliff]

I agree. Typical users aren't going to complain "hey this app doesn't feel native" or even know what that means!

However, they will likely find it harder to use without an explanation why. If most of the apps a user uses follow the guidelines of Android/iOS, and they are primarily a user of one platform, and your app doesn't follow either, it seems obvious that they won't be able to use their built-up knowledge of how apps work in general to navigate your app.

Most people I know, including myself, have found it initially a little more difficult to navigate around apps from the platform other than the one we are used to using daily.

Apps that insist on creating the same UI on both platforms can be a mixed bag, IMO. Sometimes executed well, sometimes poorly. Because of this, I usually prefer apps that separately comply with each platform.

I am however interested in playing around with Flutter soon!

[skybrian]

I kinda wonder about this stuff. Seems like it depends on your user base and I'd like to see the user study.

Helping older relatives who find touchscreens to be disconcerting (due to mistaken touches that they don't instinctively recover from by hitting the back button), I think native look and feel doesn't go nearly far enough to make things easy to use, for some audiences anyway.

[com2kid]

> If most of the apps a user uses follow the guidelines of Android/iOS, and they are primarily a user of one platform, and your app doesn't follow either, it seems obvious that they won't be able to use their built-up knowledge of how apps work in general to navigate your app.

I just checked my 8 most commonly used apps, exclusing Chrome / Gmail, FWIW I am using Android.

1. Spotify - Doesn't follow any sort of UI standards. Also randomly decides to go into drive mode.

2. Clock - Built in, follows guidelines. About 50% of the time I hit the "trash" icon when I want to reset a countdown timer.

3. Development tool, not counting this

4. Libby, awesome app to checkout books local libraries. They have some seriously cool (but not always discoverable!) UI elements that custom solve problems that have. Their audio scrubber and speed changer for audio books are really cool.

5. Tabata timer - Doesn't follow any guidelines, really really needs a "stop" button instead of relying on back button to stop a workout.

6. Audible - Custom purpose driven UI, similar to Libby but different enough it can be a bit troublesome going back and forth.

7 and 8. Games, always have a custom UI, no problem using them.

tl;dr normal doesn't exist.

[abacadaba]

> 1. Spotify - Doesn't follow any sort of UI standards. Also randomly decides to go into drive mode.

And lesson #1 in why to always follow some/any kind of UI standard.. Luckily their algorithms/service are decent.

[monocularvision]

Users dependent on accessibility will also know the difference.

[WA]

I agree. I have an app that is made with Ionic and has about 16,000 paying users. The target group aren't techies/designers. Nobody ever wrote me something like "your app feels weird". Users care more about what problem they can solve with the app.

One of my competitors has a native app, but they require an internet connection, and saving a data point has substantial lag. Parts of the UI (a graph) require a few seconds to be fully loaded, whereas my stupid Ionic app renders much bigger graphs much faster, has no "saving" lag, works offline etc.

My point is: you can screw up a native app easily as well, especially if you don't keep in mind what's blocking and what is not. Sure, at the end of the day, you can squeeze more performance and a better feeling out of a fully native app than anything Cordova-based, but this 5-10% optimization is something that non-techies really don't care about (unless maybe your app has no other USP).