6 ms·

You're in pretty much every thread that pops up as a naysayer re: not using UIKit/AppKit/etc. The thing about the link you just pointed out is that it's literal

You're in pretty much every thread that pops up as a naysayer re: not using UIKit/AppKit/etc. The thing about the link you just pointed out is that it's literally 100% UINavigationController. I've used this in projects and had to work with the native source layer - it's nothing crazy different. It's iOS-style navigation and transitions through and through.

saagarjha 9y ago
> You're in pretty much every thread that pops up as a naysayer re: not using UIKit/AppKit/etc You got me :) But yes, I'm in a lot of these threads because I do a lot of iOS development and have strong opinions on how iOS apps should work. > The thing about the link you just pointed out is that it's literally 100% UINavigationController. I've used this in projects and had to work with the native source layer - it's nothing crazy different. > It's iOS-style navigation and transitions through and through. UINavigationController is a complex beast that is often difficult to work with even in native code, because it tries to do a lot of things for you that are difficult or outright impossible to replicate if you try yourself (which isn't necessarily a good thing, but that's what we have so that's what we need to work with). Plus, a lot of this behavior "comes for free", but the downside to this is is you customize certain things you give up a lot of this behavior. So UINavigationController is not just showing a title and a back button in a box: it does things like managing transitions, animating the title when pushing onto the navigation stack, handling popping gestures, handling content insets and vibrancy, and providing certain niceties such as "tap the top of the screen to scroll up". It's a lot of things to keep track of, even for native developers, so while I'm not saying that this can't be done in JavaScript often a lot of this just ends up being reimplemented in scratch and you end up missing things. For example, the provided link, from a cursory glance that navigation controller completely butchered title handling and animations. If you want to take look at how these should work, take a look at Settings or Mail and see how the behavior differs.
- Klonoar 9y ago
  ...mmhmm, look dude, I do iOS/macOS development as well, and I've corrected you in a few threads around here already. I'm very acutely aware of how UINavigationController works. I've worked on ports of it for React Native, and even ported it backwards to macOS. All the JS in that package is doing is driving the native interactions on an in-memory UINavigationController. I've used this in recent contract work where I can confirm that the title handling and animations are the same as what you'd get with a stock UINavigationController. That project is not replicating the behavior in JavaScript, contrary to what you seem to be implying - e.g, tapping the status bar does indeed scroll shit to the top. It's all driven by JS that simply calls the native layer code. There are a lot of reasons to prefer the Apple dev ecosystem on a native level, but this is a moot point at the end of the day. Finally, look... I was your age once, and believe me, I too thought I was an expert when I was in high school. Age and time are gonna show you otherwise sooner or later. Blind allegiance to a particular tech stack isn't healthy for your career, and throwing this stuff in every thread you find just gives a really bad image to projects that are starting to beat [Apple/Qt/etc]'s dev environment at their own game. These environments need to step up their game to stay competitive, and plugging your ears (and giving this fodder to everyone else) and pretending otherwise isn't helping anything. This is almost willful ignorance on the level of Twitter's Cocoa community.
  - saagarjha 9y ago
    > All the JS in that package is doing is driving the native interactions on an in-memory UINavigationController. I've used this in recent contract work where I can confirm that the title handling and animations are the same as what you'd get with a stock UINavigationController. That project is not replicating the behavior in JavaScript, contrary to what you seem to be implying - e.g, tapping the status bar does indeed scroll shit to the top. It's all driven by JS that simply calls the native layer code. I'm aware of that–that's why I said it is possible that you can do it from JavaScript. What I'm saying is that the JavaScript layer generally causes issues like this, because UINavigationController only works in specific cases. For example, scrolling only works if you're a singular top-level scroll view. Getting the titles to animate only works if you don't try to modify it after the fact. Putting a button in the navigation bar's title view just makes it mess up when it runs its first layout pass. A lot of frameworks end up doing this, or making it very easy for this to occur, so you end up with "broken" navigation of the likes seen in that GIF. Of course, it's not unusable, so those who aren't as familiar with how it should work don't notice the difference. > Blind allegiance to a particular tech stack isn't healthy for your career I'm surprised you haven't drawn the cynical conclusion from this: that I'm desperately trying to keep my skills relevant in a world where they're being increasingly obsoleted (if you were wondering, no, this isn't true. I do have other skills as well, not including the uncanny ability to get into arguments on the internet ;) ) Thanks for the advice though, and I do mean that sincerely. > throwing this stuff in every thread you find just gives a really bad image to projects that are starting to beat [Apple/Qt/etc]'s dev environment at their own game. These environments need to step up their game to stay competitive, and plugging your ears (and giving this fodder to everyone else) and pretending otherwise isn't helping anything. Wait, are you really telling me to stop "putting down" non-native projects? Am I that persuasive that I'm giving fodder to other people? I'm really not trying to be argumentative here or pushing any sort of agenda; I'm just really, really sick of people pushing out terrible web apps that they call "native". As a developer, I agree that these projects have better tooling (Xcode isn't a particularly high bar to clear, though), but as an end user, I really hate these projects because they're clearly oriented towards developers rather than me. As someone who largely writes software for themselves, the idea that you'd make tradeoffs that harm your users is just morally appalling to me. It's not the environments that need to step up their game: it's developers who need to realize that the user is important. Sure, use JavaScript or Qt or whatever you need, but not because it makes your life easier: do it because it improves your user experience. If Cocoa just decides to mine bitcoin on your computer tomorrow I'll switch in a heartbeat, since it benefits my end users. > This is almost willful ignorance on the level of Twitter's Cocoa community. Sorry, I'm not on Twitter, so I'm not aware of what you're talking about here. Could you provide more context?
- nl 9y ago
  I think you are misunderstanding what this is. This literally is UINavigationController, controlled by Apple's JavaScriptCore. If you want extra animations or whatever, you just turn them on. There are some advantages to using native code vs ReactNative, but access to native controls and their behavior isn't one.
  - saagarjha 9y ago
    Yes, I'm aware of that; I've just finished up writing an treatise in reply to sibling comment that you might want to read. But in short: yes, you're right. React Native uses native controls, and it's probably the best solution right now. That doesn't make it good enough in my eyes, though. I want apps that I can't tell apart from "real" native ones. With Reactive Native I can do so almost invariably, and it's because someone forgot to "turn on" an animation or whatever. Or it's because they clearly just didn't understand the UI paradigm that iOS enforces. Or it might even be more insidious: React Native was just structured in a way that made easy to do the wrong thing. Whatever it is, it's clear to me that React Native still doesn't match native controls, and no, this isn't because they don't use them. It's that they use them wrong.

saagarjha 9y ago

> You're in pretty much every thread that pops up as a naysayer re: not using UIKit/AppKit/etc You got me :) But yes, I'm in a lot of these threads because I do a lot of iOS development and have strong opinions on how iOS apps should work. > The thing about the link you just pointed out is that it's literally 100% UINavigationController. I've used this in projects and had to work with the native source layer - it's nothing crazy different. > It's iOS-style navigation and transitions through and through. UINavigationController is a complex beast that is often difficult to work with even in native code, because it tries to do a lot of things for you that are difficult or outright impossible to replicate if you try yourself (which isn't necessarily a good thing, but that's what we have so that's what we need to work with). Plus, a lot of this behavior "comes for free", but the downside to this is is you customize certain things you give up a lot of this behavior. So UINavigationController is not just showing a title and a back button in a box: it does things like managing transitions, animating the title when pushing onto the navigation stack, handling popping gestures, handling content insets and vibrancy, and providing certain niceties such as "tap the top of the screen to scroll up". It's a lot of things to keep track of, even for native developers, so while I'm not saying that this can't be done in JavaScript often a lot of this just ends up being reimplemented in scratch and you end up missing things. For example, the provided link, from a cursory glance that navigation controller completely butchered title handling and animations. If you want to take look at how these should work, take a look at Settings or Mail and see how the behavior differs.

Klonoar 9y ago
...mmhmm, look dude, I do iOS/macOS development as well, and I've corrected you in a few threads around here already. I'm very acutely aware of how UINavigationController works. I've worked on ports of it for React Native, and even ported it backwards to macOS. All the JS in that package is doing is driving the native interactions on an in-memory UINavigationController. I've used this in recent contract work where I can confirm that the title handling and animations are the same as what you'd get with a stock UINavigationController. That project is not replicating the behavior in JavaScript, contrary to what you seem to be implying - e.g, tapping the status bar does indeed scroll shit to the top. It's all driven by JS that simply calls the native layer code. There are a lot of reasons to prefer the Apple dev ecosystem on a native level, but this is a moot point at the end of the day. Finally, look... I was your age once, and believe me, I too thought I was an expert when I was in high school. Age and time are gonna show you otherwise sooner or later. Blind allegiance to a particular tech stack isn't healthy for your career, and throwing this stuff in every thread you find just gives a really bad image to projects that are starting to beat [Apple/Qt/etc]'s dev environment at their own game. These environments need to step up their game to stay competitive, and plugging your ears (and giving this fodder to everyone else) and pretending otherwise isn't helping anything. This is almost willful ignorance on the level of Twitter's Cocoa community.
- saagarjha 9y ago
  > All the JS in that package is doing is driving the native interactions on an in-memory UINavigationController. I've used this in recent contract work where I can confirm that the title handling and animations are the same as what you'd get with a stock UINavigationController. That project is not replicating the behavior in JavaScript, contrary to what you seem to be implying - e.g, tapping the status bar does indeed scroll shit to the top. It's all driven by JS that simply calls the native layer code. I'm aware of that–that's why I said it is possible that you can do it from JavaScript. What I'm saying is that the JavaScript layer generally causes issues like this, because UINavigationController only works in specific cases. For example, scrolling only works if you're a singular top-level scroll view. Getting the titles to animate only works if you don't try to modify it after the fact. Putting a button in the navigation bar's title view just makes it mess up when it runs its first layout pass. A lot of frameworks end up doing this, or making it very easy for this to occur, so you end up with "broken" navigation of the likes seen in that GIF. Of course, it's not unusable, so those who aren't as familiar with how it should work don't notice the difference. > Blind allegiance to a particular tech stack isn't healthy for your career I'm surprised you haven't drawn the cynical conclusion from this: that I'm desperately trying to keep my skills relevant in a world where they're being increasingly obsoleted (if you were wondering, no, this isn't true. I do have other skills as well, not including the uncanny ability to get into arguments on the internet ;) ) Thanks for the advice though, and I do mean that sincerely. > throwing this stuff in every thread you find just gives a really bad image to projects that are starting to beat [Apple/Qt/etc]'s dev environment at their own game. These environments need to step up their game to stay competitive, and plugging your ears (and giving this fodder to everyone else) and pretending otherwise isn't helping anything. Wait, are you really telling me to stop "putting down" non-native projects? Am I that persuasive that I'm giving fodder to other people? I'm really not trying to be argumentative here or pushing any sort of agenda; I'm just really, really sick of people pushing out terrible web apps that they call "native". As a developer, I agree that these projects have better tooling (Xcode isn't a particularly high bar to clear, though), but as an end user, I really hate these projects because they're clearly oriented towards developers rather than me. As someone who largely writes software for themselves, the idea that you'd make tradeoffs that harm your users is just morally appalling to me. It's not the environments that need to step up their game: it's developers who need to realize that the user is important. Sure, use JavaScript or Qt or whatever you need, but not because it makes your life easier: do it because it improves your user experience. If Cocoa just decides to mine bitcoin on your computer tomorrow I'll switch in a heartbeat, since it benefits my end users. > This is almost willful ignorance on the level of Twitter's Cocoa community. Sorry, I'm not on Twitter, so I'm not aware of what you're talking about here. Could you provide more context?
nl 9y ago
I think you are misunderstanding what this is. This literally is UINavigationController, controlled by Apple's JavaScriptCore. If you want extra animations or whatever, you just turn them on. There are some advantages to using native code vs ReactNative, but access to native controls and their behavior isn't one.
- saagarjha 9y ago
  Yes, I'm aware of that; I've just finished up writing an treatise in reply to sibling comment that you might want to read. But in short: yes, you're right. React Native uses native controls, and it's probably the best solution right now. That doesn't make it good enough in my eyes, though. I want apps that I can't tell apart from "real" native ones. With Reactive Native I can do so almost invariably, and it's because someone forgot to "turn on" an animation or whatever. Or it's because they clearly just didn't understand the UI paradigm that iOS enforces. Or it might even be more insidious: React Native was just structured in a way that made easy to do the wrong thing. Whatever it is, it's clear to me that React Native still doesn't match native controls, and no, this isn't because they don't use them. It's that they use them wrong.