> 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.
Most of those issues that you bring up with UINavigationController are, while annoying, not actually _that_ common in apps, and people run into them at the native level too - it's not entirely a JS issue. Provided you're not doing anything too against the grain (which the Wix API more or less protects novice users from doing), you're unlikely to experience too many issues and it functions as an almost completely indistinguishable UINavigationController experience for pretty much everyone.
As an aside, if React Native would fix TouchableOpacity to follow platform convention, most people would have difficulty detecting RN apps.
> 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...
I didn't draw that conclusion, you're correct - but had it been the case, I really wouldn't have blamed you. I prefer writing [UI|App]Kit day to day and I'd hate to not be able to. I'm more than capable in... just about any programming ecosystem, but they're simply not as enjoyable for reasons that are tough to put into words.
>Wait, are you really telling me to stop "putting down" non-native projects?
No, not at all. I put down Qt all the time myself, but then again, how do you define native? ;)
My point here is that coming into these threads and saying that people should be building native iOS/macOS/etc is a bit of a rough sell, given how nuanced actually developing at the native level for those platforms is (e.g, most people wouldn't know that a UITableView section header is really a grouped row in NSTableView - AppKit is woefully undocumented and cobweb filled in 2018). Apple needs to get their shit together, and maybe that's what Marzipan or whatever is - in fact, I really hope it is.
Until then, there's simply no compelling reason to build native [UI|App]Kit when the writing is on the walls. Instead of fighting this battle, people need to complain (loudly, very loudly) to Apple. Electron & co are not taking over because they're inherently better as an approach, but because native platforms are literally just rolling over.
>it's developers who need to realize that the user is important
This is idealism, and I applaud you for it, but it's honestly misplaced (and I wish it wasn't). The user is only important _when you actually have users_. For most apps these days, time to market and getting it out the door trumps whatever perceived native benefits there are.
I personally build for quality in my projects because it's what I want representing me, and that's sadly about the only justifiable reason these days.
>Sorry, I'm not on Twitter, so I'm not aware of what you're talking about here. Could you provide more context?
Was a bunch of hubbub recently over this article (http://inessential.com/2018/04/25/youre_practically_a_mac_de...), where it boiled down to Xcode/Apple-ecosystem developers decrying alternative approaches (Electron, RN, etc), and more or less saying that it should be easy to just reuse the same stuff for a Mac app. The argument that most non-Xcode/Apple-ecosystem devs made was that Apple:
- Really, really sucks when it comes to Mac/AppKit documentation these days, and discoverability in comparison to the likes of JS and such is nowhere near the same.
- Live reload > compile and run, Swift playgrounds aren't a solution.
- [Almost any JS unit testing framework] > Unit testing in Xcode
The tl;dr = Apple is getting off relatively easily for not keeping their dev environments competitive, and people complaining about Electron & co making inroads should really be complaining at Apple for neglecting this stuff. I tend to agree, as noted earlier... and, hell, it's not even limited to the above points.
For example:
- Why the hell are the Apple forums not scrapped and dumped into a hosted StackExchange? It's 2018.
- Why the hell is Radar still a black hole of information? There are better ways to do this nowadays.
- Why the hell is so much of Cocoa & AppKit completely un-Google-able? Half the time you try to find something, you wind up in an archived email thread from the early 2000s. There is no way a new developer is going to put up with this crap in 2018. Shit, if it wasn't for NSHipster transcribing WWDC videos we'd still be sitting there watching video content just to understand a programming ecosystem.
- Why the hell does every Cocoa/AppKit dev put all their stuff on Twitter these days? They're just as responsible as Apple at this point. The JS community documents the everloving bajeezus out of their projects, whereas the only mention you'd find about, say, NSCollectionView frame/bounds change notifications is on Twitter. Nothing from Twitter is easily found in Google.
- This list could go on - e.g, why the hell are we _still_ dealing with Cells in AppKit for things like a TextField? We got rid of them for NSTableView, fix the rest already.
What's really painful about all of this is also that Apple is clearly capable of doing better - Swift alone is a massive improvement in how they've communicated, built, and shipped a developer oriented product. People not holding them accountable and instead expecting the developer community to bend over backwards and build for an aging platform is insanity, especially when this is the most valuable company in the world that we're discussing.
* = Edits are formatting attempts, because... well, this is another platform that could modernize a bit.