Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SwiftUI

developer.apple.com

Post reply on HN
Print view View original

251–260 of 394 posts

Re: SwiftUI

#251

Post by gwright »

oakesm9 wrote: post #233
gwright wrote: post #205

Earlier quoted context omitted.

That is exactly what I said when I saw the code on the screen. Now if they released a development environment for Android also.... (wishful thinking)

If you mean and official declarative UI library then Google released one of those at Google IO this year: https://developer.android.com/jetpack/compose

I am very interested in multi-platform Kotlin. I'm not sure how far it will get but on the surface I think it is more likely for Kotlin to work on iOS than Swift on Android.

Still learning about compose.

Re: SwiftUI

#252

Post by tspike »

robertAngst wrote: post #228
zapzupnz wrote: post #221

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?

> what are you paying for with Apple?

For me, it's vertically integrated privacy.

Re: SwiftUI

#253

Post by tspike »

vedantroy wrote: post #237

This is definitely an overly ambitious project idea, but now that Google has Jetpack Compose and Apple has SwiftUI, and the web has React, I wonder if it would be possible to make a "meta-framework" that uses a single code-base to compile user written code into source code written in those 3 frameworks respectively. Then you would get truly native, cross-platform development. Now, the probability this would ever work…

It would be great until you need to debug something. Then it would be a nightmare.

Re: SwiftUI

#254

Post by artemiszx »

Thinking about starting a new project over the summer. But seeing the demos it seems just starting something in UIKit now is a bad idea?

Re: SwiftUI

#255

Post by weiming »

gschrader wrote: post #127
chkgk wrote: post #42

I didn't catch it. Is Xcode 11 (beta) available already? Do I need macOS Catalina (beta) to run it? I seem to have missed the crucial information and cannot find it on apples developers pages...

The direct download is here: https://developer.apple.com/services-account/download?path=/... for some reason my account only shows "There’s currently no beta software available for download."

https://xcodereleases.com

Best-kept secret with direct download links (from apple.com)

Re: SwiftUI

#256

Post by pault »

archagon wrote: post #242

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…

I can only speak for React, but the declarative component model doesn't eliminate state or imperative code, it just nudges you towards separating your stateful code from your layout/rendering code. In the React/Redux convention, your application is one big state machine with transitions encoded in reducers, and your state -> view data transformations in "selectors". View components are composed into one big pure function of state. Putting barriers between those classes of functionality makes it much easier to compose complex behavior from small, focused functions. Obviously you can write code with those properties in any context, but conventional React/Redux architecture makes the lines more explicit, which is why I like it. Lots of people hate it.

Re: SwiftUI

#257

Post by munificent »

gwright wrote: post #205
mooman219 wrote: post #79

Earlier quoted context omitted.

This looks very similar to Flutter, I wouldn't be surprised if they took some ideas from that which is all well and good; UI construction needs a facelift.

That is exactly what I said when I saw the code on the screen. Now if they released a development environment for Android also.... (wishful thinking)

If you want a Flutter-inspired framework that works on iOS and Android, have you considered, uh, Flutter?

Re: SwiftUI

#258

Post by munificent »

vedantroy wrote: post #237

This is definitely an overly ambitious project idea, but now that Google has Jetpack Compose and Apple has SwiftUI, and the web has React, I wonder if it would be possible to make a "meta-framework" that uses a single code-base to compile user written code into source code written in those 3 frameworks respectively. Then you would get truly native, cross-platform development. Now, the probability this would ever work…

> I wonder if it would be possible to make a "meta-framework" that uses a single code-base to compile user written code into source code written in those 3 frameworks respectively.

Flutter targets native code on Android and iOS and JavaScript for the web. It has very mature compilers for all three.

Re: SwiftUI

#259

Post by nexuist »

archagon wrote: post #242

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 where the cloud contains most of the business logic and the app is a thin visual client proxying the data.

You could argue that, for example, a first person shooter is not CRUD heavy. But after the match, when you're looking at leaderboards or sending friend requests or chatting with your friends in the lobby...guess where that UI is updating from?

Yep, another CRUD API. It's everywhere. I really want someone to prove me wrong because I want to expand my horizons - what the hell isn't a CRUD thing these days, other than completely offline apps?

Re: SwiftUI

#260

Post by mmargerum »

HillaryBriss wrote: post #188
pier25 wrote: post #183

Earlier quoted context omitted.

Native controls aren't drawn too?

yes, they're drawn too. but, i think what the above comment is pointing out is that Flutter itself does the drawing, instead of delegating the drawing to iOS or Android native widgets.

More than just drawing. They have to reimplement all of the behaviors of the built in controls. I'm sure google is up to the task, but my experience has been there's always things missing and and lag behind native .
Post reply on HN