Mike Zornek:
The LG 49 inch UltraWide monitor is pretty cool, but not very Mac compatible (specifics defects below). Next up for me is the Apple Store approved, 23.7-inch LG UltraFine 4K Display, which will trade screen real estate for retina, better color and native controls.
These days, it seems like the only way to get a 4K or 5K Mac display with the proper resolution is to buy an iMac.
Previously:
Update (2019-08-02): Mike Zornek:
The real benefit of this monitor however comes from its nearly seamless integration with Mac OS X. All of the expected brightness and volume controls work from the keyboard. There is no power button on the display and once you connect the Thunderbolt cord to the MacBook Pro the monitor wakes up and also starts charging the laptop. Even wake from sleep is fairly reliable.
[…]
I would have also appreciated a basic camera for conference calls. I have an external USB camera I can setup (with ANOTHER adaptor) but not having a camera/microphone for this common need seems like an oversight for such a high end monitor.
My final complaint, and this isn’t for the monitor directly, is that using it makes my MacBook Pro (15-inch, 2016) run hot. Check out this graph, the early days are when I was working from home with the monitor attached and then the later days are me on the road at a conference with no monitor. Connecting the monitor seems to double the temperature, just to push the pixels let alone when I’m really pushing the CPU with code compliers or video exports.
Display LG Mac Retina
Martin Pilkington:
The problem I had with porting it to iOS in the first place became even more stark when it was “ported back” using Catalyst. UIKit is still not powerful enough to create a UI that feels great on the Mac. I can’t use NSColorWell and the built-in colour picker, and I can’t convert the rating picker to an NSPopUpButton, as you can’t combine both AppKit and UIKit in the same view hierarchy. This left the inspector looking rather forlorn and out of place.
[…]
I’m fully behind [SwiftUI] as the future of the platform, which is very much different to how I felt about Swift itself when it was first released. Unfortunately the thing SwiftUI does share with Swift 1.0 is that it’s very much a beta technology that is in no way ready for extensive use.
[…]
The biggest problem though is Swift itself. Having small, lightweight types that have a plethora of extensions that add functionality and protocol conformance is great way to write flexible and composable APIs, but it makes learning those APIs a nightmare. It’s bad enough for the Swift standard library, but SwiftUI takes it to a whole new level.
The lack of header files for documentation is a problem.
Honestly, after starting out with a lot of hope of going with either Catalyst or SwiftUI I’ve ended up being somewhat disillusioned with both of them. It seems silly, but the least friction I had getting an app that worked on both Mac and iPad was with the first attempt, where I had separate AppKit and UIKit apps. Yes, it requires more work and has less shared code, but it allows me to build for each platform with minimal frustration, and without having to hobble one app to allow for the other, as using Catalyst would require.
Previously:
Update (2019-06-27): Oluseyi Sonaiya:
Lots of languages provide excellent, browseable code interface documentation without using header files. That’s a red herring and false criticism of Swift.
I don’t want actual header files, just better tooling for the auto-generated Swift interfaces (which include the doc comments) so that they can serve the same documentation functions that headers did. A single 10,165-line file is hard to browse, search, and diff.
Catalyst (Marzipan) Cocoa Documentation iOS iOS 13 iPad Mac macOS 10.15 Catalina Programming Swift Programming Language SwiftUI
