Live data from Hacker News

SwiftUI

developer.apple.com

271–280 of 394 posts

Re: SwiftUI

#271
post #269

Earlier quoted context omitted.

It looks like Jetpack Compose is not really done yet. It's pre-alpha and the Jetpack Compose doc page says don't use it for production. https://developer.android.com/jetpack/compose/ I may be missing something, but SwiftUI seems to be pretty much ready to go today.

Ready to go today if you're only supporting iOS 13+ Which for most companies is 2+ years away

I stand corrected. thanks.

Re: SwiftUI

#272

I'm laughing at all the handwringing over Marzipan in the lead-up to this year's WWDC. The future of MacOS development is not Marzipan and never was. The future is SwiftUI.

"A rose by any other name would smell as Marzipan". Even if it's called SwiftUI and not Marzipan, it still has all the same future problems as when it was called Marzipan [1] [1] https://blog.iconfactory.com/2019/05/what-to-expect-from-mar...

SwiftUI is totally unrelated to Marzipan.

Re: SwiftUI

#273

Earlier quoted context omitted.

Because not all of your "fellow developers" have the same priorities as you. For a lot of developers, targeting just the Apple platforms is still a worthwhile investment in itself: Apple's customers tend to pay higher prices for quality Mac software — yes, outside the Mac App Store, too — and they will very often be happy to pay for the accompanying iOS app if it's worth doing so. There have been Apple-only developme…

Given the high cost, high cost options exist on other platforms that are also fantastic. So if everyone can spend 3,000 dollars and get best in class computing, what are you paying for with Apple? They have lots of marketing that psychologically makes you feel good?

Perhaps they like the things that they're paying for, and no one's tricking them into anything, and maybe they even looked at those alternatives and still decided that they liked what they had. Crazy, I know. Something to consider though.

Re: SwiftUI

#274
This is exactly what we did with Creo a couple of years ago: design, preview and development in a single tool. We rewritten UIKit from scratch in order to be able to preview iOS code on MacOS. Looks like we did it right. https://creolabs.com

Re: SwiftUI

#275

One more blow to the head for objective-c. Wonder if this the final nail in the coffin.

Given that Craig Federighi basically said this type of migration only comes around every 20 years, I would imagine Objective-C is dead. I do hope they actually take the time and fix the Swift examples so they are updated. This does hurt. I've been programming Objective-C since NeXTSTEP and love it. Swift is still like Perl for me. Something I will use for programming for money, but not enjoy for one minute. I loved t…

How is swift a javascript clone?

Objective c is insanely verbose.

Re: SwiftUI

#276

Earlier quoted context omitted.

You're welcome to your definition, but if you think developing for desktops, notebooks, smartphones, and tablets, with all the differences they encompass is trivial, you're in for a shock. Even with other cross-platform offerings like Flutter, React, Electron and so on, getting one codebase to work out of the box on just two platforms can be a challenge. On mobile, there tends to be a need to drop down from the cross…

You are literally the only person I have ever heard to use "cross-platform" in the sense you just described. Did you mean "cross form-factor" or something?

Bit like Microsoft in 2005. "Cross platform" meaning Windows, Windows Server, Windows Mobile, Windows CE...

Re: SwiftUI

#277
post #192

Does the syntax sort of kind of remind anyone else of Shoes?[1] http://shoesrb.com/

The nesting makes it look similar but Shoes isn't declarative so it works very differently under the hood

Re: SwiftUI

#278

Lots of engineers are suggesting that SwiftUI, plus other declarative frameworks, might be "the future" of app development. However, I can't help but feel that this paradigm would work best when your app is a fairly basic CRUD thing. If you're working with highly interactive interfaces, complex animations, or dense, layered documents (DAWs, video editors), it seems that you would need explicit state and imperative co…

"However, I can't help but feel that this paradigm would work best when your app is a fairly basic CRUD thing" Honestly, this is something I've been struggling with coming to terms to for a while. Really, what mobile app isn't just a CRUD thing? Literally every 3rd party app I can think of on my phone talks to some REST service in some way. Even the video games, photo editors, notes apps, etc. They all use the cloud…

I feel like CRUD can be a simplistic categorisation at times. Take a look at the Slack app, for example. It's got chat messages. Also rich media. And threading. And user profiles. And notifications. But each of those is "just" CRUD. That doesn't mean it's a walk in the park. By broad definition just about every piece of software ever created is CRUD.

Re: SwiftUI

#279

Lots of engineers are suggesting that SwiftUI, plus other declarative frameworks, might be "the future" of app development. However, I can't help but feel that this paradigm would work best when your app is a fairly basic CRUD thing. If you're working with highly interactive interfaces, complex animations, or dense, layered documents (DAWs, video editors), it seems that you would need explicit state and imperative co…

Agreed... especially in React Native. You quickly run into a wall for some more advanced things because of how it's designed. (Mostly imperative actions/animations, etc)

Re: SwiftUI

#280
post #109
post #80

Earlier quoted context omitted.

@State var model = Themes.listModel I haven't tried it out, but the above looks more like MobX: @observable model = new MyListModel();

I think it's a closer analogue to React.useState.

Does that mean that UI will automatically get updated when the model changes, and you no longer need a mess of dependencies, like "if A changed, update X and Y".
Post reply on HN