Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

For Mac, I'm not super in touch, but I get the impression Apple is all in on Swift UI, and their developer support model is clear: use old tech at your peril, it may not be supported in the next version. So I would use Swift UI.

For Windows, I think it goes the other way. Microsoft is always coming around with a new UI model that's half-ass and will be dead next year. Use the old ways: MFC will never die.



Apple Nuke their entire developer ecosystem from orbit every few years. Using a cross-platform UI like Qt insulates you from this to an extent. But the downside is that you never get it to look quite 100% native and you may not have easy access to the latest bells and whistles from Apple.

Microsoft can't seem to make up their mind on what UI platform people should be using. It's a mess. But they generally do support old platform, unlike Apple. I gag at thought of writing MFC code in 2024. But each to their own.


>I gag at thought of writing MFC code in 2024.

In any year. Could never grok it, when it was newish, what with its crazy opaque AFX macros, although I could somewhat easily understand Win 32 C programming (Petzold book etc.), even though that was lower level, and I was new to event-driven GUI programming then.


The Win32 API is also seriously ugly. All those struct parameters, mostly full of zeros, and the hungarian notation. I know it is something from an earlier time and can't be changed without breaking everything, but it was hideous even by the standards of the day.


Yes, it was. Delphi, a few years later, was a lot better ...


I've heard a lot of horror stories with Swift UI.

I think it's crazy that it's closed source too. It's a big black box which makes debugging hard. Plus its the kind of framework that does a lot of magic stuff where you scratch your head wondering what is going on.


I wouldn’t say I’ve had horror stories just minor gripes and frustrations. You can mix and match AppKit and UIKit with SwiftUI. So there is always an escape hatch.

SwiftUI is insanely productive when it comes to building mostly simple list and form applications.

I highly recommend that you try it, you can always build a component or large sections using UIKit if you run into issues.

At Ditto almost all of our enterprise customers use SwiftUI over UIKit because SwiftUI is so productive for the vast majority of use cases. Does it have parity with UIKit? No… but it’s never been a dealbreaker for us.


Yeh horror story was probably too strong a word. I need to try it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: