4 ms·

> At least it's better than Electron, I guess. It seems ridiculous that Apple wouldn't put up the resources to implement these apps properly on macOS From peop

by raydev 8y ago

> At least it's better than Electron, I guess. It seems ridiculous that Apple wouldn't put up the resources to implement these apps properly on macOS From people with experience in both, UIKit is better designed than AppKit. Apple sees this and I think it's pretty clear their intent is for UIKit to supersede AppKit on macOS. One day. Apple unfortunately shipped what is effectively the alpha version to the public.

saagarjha 8y ago
> From people with experience in both, UIKit is better designed than AppKit. Debatable. AppKit might have a bunch of legacy cruft, but it also has some truly beautiful things like bindings, or how certain interface controls work. It's a much more mature framework.
- arcticbull 8y ago
  Bindings (and KVO/KVC that support them) are magic-oriented programming that make me sad. One has to assume they very specifically didn't make the cut when iOS and UIKit were designed :P
- therockhead 8y ago
  Interesting, i found bindings only useful for the most basic of UI and not really worth the effort.
TheAceOfHearts 8y ago
> From people with experience in both, UIKit is better designed than AppKit. Can you expand on this? I haven't done iOS development, so I'd be interested in what ways people consider UIKit superior. Although it wouldn't surprise me, since it came much later than AppKit and they had hindsight when designing it.
- GeekyBear 8y ago
  The topic of making UIKit available to developers on the Mac comes up from time to time. People seem to go back and forth on it, as in this post from a couple of years ago. >The thing is, UIKit "just works" (most of the time at least). AppKit has so much historical garbage that it's become a pain to work with for modern macOS apps. It's still really hard to make simple things like customizing system controls and Core Animation doesn't work as well on it as it does on UIKit. https://medium.com/@guilhermerambo/why-uikit-for-macos-is-important-ff4e74a82cf0 https://medium.com/@guilhermerambo/why-uikit-for-macos-is-im...
  - saagarjha 8y ago
    I'd have to disagree with him here; he's unnecessarily biased against AppKit since he's more used to how UIKit is supposed to work.
arcticbull 8y ago
I did macOS development with AppKit from 2003-ish through 2012, then iOS with UIKit since. It's not that one's better than the other, UIKit is just newer. It wasn't clean-roomed, it was heavily inspired by the best parts of AppKit. Since then, many of the best parts of those changes have been fed back, yet again, into AppKit (view-based table views, view controllers, layer-backed views, CoreAnimation, etc). They're built to serve different audiences, just like iOS and macOS they support. macOS and AppKit are designed around multiple windows, side-by-side, with very specific mouse and keyboard navigation conventions. iOS and UIKit are designed around single windows with nested navigation stacks, view controllers and gesture-based navigation. One tool for each job. It's not about replacement. As always, you can use any API to implement any piece of software. It behooves you to focus on your user and pick the one that lets you provide the best experience. They're the same programming languages and just different accents on the framework. You'll figure it out if you care.
- ken 8y ago
  Speaking only for myself, I have no problem with windows/screens or mouse/taps being different. The parts that baffle me are those which have nothing to do with the different interaction models, and are simply different for no apparent reason. NSColor/UIColor are different, and it's not like one color class is better for windowed versus non-windowed colors. NSBezierPath/UIBezierPath perform the same task yet often the same methods have different names. I've wasted a bunch of time making extensions so that one OS's classes would look like the other (annoying but not difficult). The fact that every developer has to do this is just silly. Apple's own WWDC video on iWork essentially says "Because we wanted it to be cross-platform, we avoided drawing the standard way, and draw all content using CALayers instead". If Apple did nothing else but make the parts that work identically be named identically, that would be Marzipan enough for me.
  - arcticbull 8y ago
    I agree the color and path classes being different is pretty frustrating. I think the argument that can be made is that the UI should be different enough between iOS and macOS that the incentive to share code at the UI level is limited. Sharing the model and business logic is, after all, seamless. There was a big push in the early days to true the lower-level APIs up. I also understand why they could justify to themselves a code-level compatibility barrier to make people think twice about sharing UI elements in a sub-optimal way. I'm pretty tepid on it, tbh.
bunnycorn 8y ago
> Apple unfortunately shipped what is effectively the alpha version to the public. Apple hasn't shipped any library to the public.
- raydev 8y ago
  I didn't make that claim. There are 4 apps available for macOS that are entirely written with UIKit, with the exception of the bridge required to interact with macOS. They shipped those apps to the public, and they feel like incomplete apps.

by raydev 8y ago

saagarjha 8y ago

> From people with experience in both, UIKit is better designed than AppKit. Debatable. AppKit might have a bunch of legacy cruft, but it also has some truly beautiful things like bindings, or how certain interface controls work. It's a much more mature framework.

arcticbull 8y ago
Bindings (and KVO/KVC that support them) are magic-oriented programming that make me sad. One has to assume they very specifically didn't make the cut when iOS and UIKit were designed :P
therockhead 8y ago
Interesting, i found bindings only useful for the most basic of UI and not really worth the effort.

TheAceOfHearts 8y ago

> From people with experience in both, UIKit is better designed than AppKit. Can you expand on this? I haven't done iOS development, so I'd be interested in what ways people consider UIKit superior. Although it wouldn't surprise me, since it came much later than AppKit and they had hindsight when designing it.

GeekyBear 8y ago
The topic of making UIKit available to developers on the Mac comes up from time to time. People seem to go back and forth on it, as in this post from a couple of years ago. >The thing is, UIKit "just works" (most of the time at least). AppKit has so much historical garbage that it's become a pain to work with for modern macOS apps. It's still really hard to make simple things like customizing system controls and Core Animation doesn't work as well on it as it does on UIKit. https://medium.com/@guilhermerambo/why-uikit-for-macos-is-important-ff4e74a82cf0 https://medium.com/@guilhermerambo/why-uikit-for-macos-is-im...
- saagarjha 8y ago
  I'd have to disagree with him here; he's unnecessarily biased against AppKit since he's more used to how UIKit is supposed to work.

arcticbull 8y ago

I did macOS development with AppKit from 2003-ish through 2012, then iOS with UIKit since. It's not that one's better than the other, UIKit is just newer. It wasn't clean-roomed, it was heavily inspired by the best parts of AppKit. Since then, many of the best parts of those changes have been fed back, yet again, into AppKit (view-based table views, view controllers, layer-backed views, CoreAnimation, etc). They're built to serve different audiences, just like iOS and macOS they support. macOS and AppKit are designed around multiple windows, side-by-side, with very specific mouse and keyboard navigation conventions. iOS and UIKit are designed around single windows with nested navigation stacks, view controllers and gesture-based navigation. One tool for each job. It's not about replacement. As always, you can use any API to implement any piece of software. It behooves you to focus on your user and pick the one that lets you provide the best experience. They're the same programming languages and just different accents on the framework. You'll figure it out if you care.

ken 8y ago
Speaking only for myself, I have no problem with windows/screens or mouse/taps being different. The parts that baffle me are those which have nothing to do with the different interaction models, and are simply different for no apparent reason. NSColor/UIColor are different, and it's not like one color class is better for windowed versus non-windowed colors. NSBezierPath/UIBezierPath perform the same task yet often the same methods have different names. I've wasted a bunch of time making extensions so that one OS's classes would look like the other (annoying but not difficult). The fact that every developer has to do this is just silly. Apple's own WWDC video on iWork essentially says "Because we wanted it to be cross-platform, we avoided drawing the standard way, and draw all content using CALayers instead". If Apple did nothing else but make the parts that work identically be named identically, that would be Marzipan enough for me.
- arcticbull 8y ago
  I agree the color and path classes being different is pretty frustrating. I think the argument that can be made is that the UI should be different enough between iOS and macOS that the incentive to share code at the UI level is limited. Sharing the model and business logic is, after all, seamless. There was a big push in the early days to true the lower-level APIs up. I also understand why they could justify to themselves a code-level compatibility barrier to make people think twice about sharing UI elements in a sub-optimal way. I'm pretty tepid on it, tbh.

bunnycorn 8y ago

> Apple unfortunately shipped what is effectively the alpha version to the public. Apple hasn't shipped any library to the public.

raydev 8y ago
I didn't make that claim. There are 4 apps available for macOS that are entirely written with UIKit, with the exception of the bridge required to interact with macOS. They shipped those apps to the public, and they feel like incomplete apps.