3 ms·

As someone (apparently the only one in this thread) that writes macOS and iOS apps, I can't wait for NSView and it's stupid lower-left cartesian coordinate syst

As someone (apparently the only one in this thread) that writes macOS and iOS apps, I can't wait for NSView and it's stupid lower-left cartesian coordinate system to die. UIKit is so much better in so many ways, it's time NSView and its friends are all put out to pasture.

wtallis 9y ago
Unifying the APIs that exist in slightly different versions on both platforms makes sense. But it's dangerous to talk like that frees you from having to design and implement separate user interfaces for handheld touchscreens and for desktops with keyboard+mouse. I like the idea of getting a compiler error when you try to deploy a touchscreen UI to my MacBook Pro. I paid good money for that Retina display because I want to have a lot of information on screen. I don't want it wasted by 200px buttons.
neonhomer 9y ago
I've had many years of experience with iOS and then started working on a macOS app a year or so ago. Everything seemed overly complicated compared to iOS development. I ended up using a web view and did a lot of front-end work via HTML to save time!
- tinus_hn 9y ago
  UIKit is much more limited than AppKit because it was meant to run on devices with limited resources. In fact, people used to complain about all the things you couldn't do on iOS devices that you could on the Mac.
Klonoar 9y ago
I end up just using a subclass with isFlipped returning true 90% of the time. I've found that I rarely need to deal with the lower-left issue after that... what's your biggest pain point after that? I look forward to this from Apple, because then I could scrap so much of my own stuff that's aliasing the two platforms. I think people who haven't built for these platforms don't understand that it's not about Apple letting you provide the same UI on two different platforms, but about getting rid of the lower-level differences between the two that don't need to exist in the first place. It's strange to see so many people both here and over on Reddit take issue with Apple doing this - you can't sit there and complain about Electron taking over and then decry a company literally giving you a better option. I'd gladly run a Slack client on my desktop if I could get the iOS build, and I'd really enjoy having RobinHood or Tinder or any number of apps on my desktop so I don't need to pull out my phone (or open a browser) for them. As it stands right now, cross-building your app for desktop from iOS is a rabbit hole that most people are right to shy away from as there's a lot of odd knowledge that's historically been needed to make it work. For example, NSTableView in 10.13 finally supports AutoLayout without needing to hack around it with a caching view, making it much closer to UITableView. That alone makes certain views much easier. Collection Views also only recently got closer to their UIKit counterparts, and it's made that much more usable as a result. Before these things, there was _so much_ glue code to reuse the same stuff. Sharing layout code before was possible, but an extreme exercise in frustration for a lot of people - now it's getting closer to a 1:1. Using any of the littered unmaintained frameworks for "UIKit in AppKit" is also usually not that great, since it's another API to learn that's most unofficial and they've almost all been abandoned over the years. Also, as one last personal comment, Apple needs to port UINavigationController - I ended up rolling my own (with the whole header view/etc), which is horrendously annoying to do. While I totally understand that mobile != desktop, it's 2017 and people have gotten slightly used to some mobile interfaces working on desktop. At the end of the day it's a simple stacked navigator that'd make code reuse a lot easier. Hell, port the API and have it display differently for all I care. Ninja Edit: if you're an Electron fan, and Apple had frameworks that worked the same on Mac/iOS, you could avoid Electron on iOS if you had a React Native app that could now cross compile (not using the odd third party framework that exists and is never really feature-parity with actual React Native).

wtallis 9y ago

Unifying the APIs that exist in slightly different versions on both platforms makes sense. But it's dangerous to talk like that frees you from having to design and implement separate user interfaces for handheld touchscreens and for desktops with keyboard+mouse. I like the idea of getting a compiler error when you try to deploy a touchscreen UI to my MacBook Pro. I paid good money for that Retina display because I want to have a lot of information on screen. I don't want it wasted by 200px buttons.

neonhomer 9y ago

I've had many years of experience with iOS and then started working on a macOS app a year or so ago. Everything seemed overly complicated compared to iOS development. I ended up using a web view and did a lot of front-end work via HTML to save time!

tinus_hn 9y ago
UIKit is much more limited than AppKit because it was meant to run on devices with limited resources. In fact, people used to complain about all the things you couldn't do on iOS devices that you could on the Mac.

Klonoar 9y ago

I end up just using a subclass with isFlipped returning true 90% of the time. I've found that I rarely need to deal with the lower-left issue after that... what's your biggest pain point after that? I look forward to this from Apple, because then I could scrap so much of my own stuff that's aliasing the two platforms. I think people who haven't built for these platforms don't understand that it's not about Apple letting you provide the same UI on two different platforms, but about getting rid of the lower-level differences between the two that don't need to exist in the first place. It's strange to see so many people both here and over on Reddit take issue with Apple doing this - you can't sit there and complain about Electron taking over and then decry a company literally giving you a better option. I'd gladly run a Slack client on my desktop if I could get the iOS build, and I'd really enjoy having RobinHood or Tinder or any number of apps on my desktop so I don't need to pull out my phone (or open a browser) for them. As it stands right now, cross-building your app for desktop from iOS is a rabbit hole that most people are right to shy away from as there's a lot of odd knowledge that's historically been needed to make it work. For example, NSTableView in 10.13 finally supports AutoLayout without needing to hack around it with a caching view, making it much closer to UITableView. That alone makes certain views much easier. Collection Views also only recently got closer to their UIKit counterparts, and it's made that much more usable as a result. Before these things, there was _so much_ glue code to reuse the same stuff. Sharing layout code before was possible, but an extreme exercise in frustration for a lot of people - now it's getting closer to a 1:1. Using any of the littered unmaintained frameworks for "UIKit in AppKit" is also usually not that great, since it's another API to learn that's most unofficial and they've almost all been abandoned over the years. Also, as one last personal comment, Apple needs to port UINavigationController - I ended up rolling my own (with the whole header view/etc), which is horrendously annoying to do. While I totally understand that mobile != desktop, it's 2017 and people have gotten slightly used to some mobile interfaces working on desktop. At the end of the day it's a simple stacked navigator that'd make code reuse a lot easier. Hell, port the API and have it display differently for all I care. Ninja Edit: if you're an Electron fan, and Apple had frameworks that worked the same on Mac/iOS, you could avoid Electron on iOS if you had a React Native app that could now cross compile (not using the odd third party framework that exists and is never really feature-parity with actual React Native).