SwiftUI • Hacker News Board

Re: SwiftUI

#351

Post by jiyinyiyong » Tue, Jun 04, 2019, 3:12 PM UTC

diroussel wrote: post #315

jiyinyiyong wrote: post #294

Earlier quoted context omitted.

If Apple is willing to create a GUI tool for generating the DSL used in SwiftUI, it's not far from enabling UI designers to generate UI by themselves. We may need a lower-level representation for the DSL though. I think it's not a problem that we go one step further and make it happen in the next few years.

You could call this hypothetical tool Interface Builder.

Watched several short videos, it seems they are already doing that by dragging component to generate code, by configuring parameters in the code with panels. It's very approaching.

Re: SwiftUI

#352

Post by HillaryBriss » Tue, Jun 04, 2019, 3:54 PM UTC

myko wrote: post #269

HillaryBriss wrote: post #191

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

To add a bit more detail: the required level for other Apple OSs are macOS 15+, tvOS 13+ and watchOS 6+.

Re: SwiftUI

#353

Post by TheRealDunkirk » Tue, Jun 04, 2019, 4:47 PM UTC

teilo wrote: post #194

TheRealDunkirk wrote: post #18

Other than a few-hour intro seminar on building iOS apps, almost 10 years ago, I've never written anything in Swift. The announcements around it today got the biggest reactions from the crowd. Is is really great, blasé, or too early to tell?

You were not using Swift 10 years ago, or even almost 10 years ago. It was released in 2014.

Ah, now I see the reason for the downvotes. I just meant "Apple's language for doing iPhone apps," and, of course, that was Obj-C back then. I haven't thought about it since.

Re: SwiftUI

#354

Post by abalone » Tue, Jun 04, 2019, 5:55 PM UTC

I’m wondering what this could mean for replacing React Native. Obviously SwiftUI is geared for Apple’s platforms but overall it seems pretty high level and perhaps amenable to being adapted to Android by somebody. Swift is open source after all.

This would solve a problem a lot of devs have in deciding how to build a cross platform app. We don’t want to give up first class support for each platform but it’s silly to have completely separate codebases.

I hear even Apple has React Native dev groups.

Re: SwiftUI

#355

Post by pier25 » Tue, Jun 04, 2019, 7:30 PM UTC

saagarjha wrote: post #334

pier25 wrote: post #291

Earlier quoted context omitted.

Actually no, Flutter doesn’t do the drawing. It’s done by Skia, much like Cocoa native controls are drawn by Quartz. There isn’t much of a difference between Flutter controls and native controls, other than being a reimplementation in some cases.

> There isn’t much of a difference between Flutter controls and native controls Except that they behave quite differently…

I meant technically speaking. Obviously the implementation or the user experience are a different matter.

Re: SwiftUI

#356

Post by pier25 » Tue, Jun 04, 2019, 7:33 PM UTC

mpweiher wrote: post #326

pier25 wrote: post #291

Earlier quoted context omitted.

Actually no, Flutter doesn’t do the drawing. It’s done by Skia, much like Cocoa native controls are drawn by Quartz. There isn’t much of a difference between Flutter controls and native controls, other than being a reimplementation in some cases.

> other than being a reimplementation in some cases. Hmm...that's pretty much the entire difference between native and non-native controls.

Yes, and that is precisely my point.

A previous commenter implied that there somehow native controls were technically different than Flutter controls.

Obviously the rendering stack is different but Skia is as native as Quartz is.

Re: SwiftUI

#357

Post by OkGoDoIt » Tue, Jun 04, 2019, 9:02 PM UTC

For more information, there's a much more in-depth demo in the "Platforms State of the Union" session, which is now posted at https://developer.apple.com/videos/play/wwdc2019/103/

Re: SwiftUI

#358

Post by astrange » Tue, Jun 04, 2019, 9:23 PM UTC

tsss wrote: post #342

astrange wrote: post #282

Earlier quoted context omitted.

> It seemed crazy and old school to me to have the UI stuff that IB generates stored in XML - I definitely thought it should generate the same code that you would write to do it programmatically. Most good ideas are old school. Data is more powerful than code because it can be analyzed in more ways - for instance, you can extract all the UI and text from an app, localize and re-insert it, then verify the UI won't bre…

Bullshit, any language with a macro system can do this. LISPs in particular are known for being code and data at the same time and this idea is way more old school than XML. You could also make a DSL that builds something like an AST of your UI in a similar fashion to free monads. It's no surprise that XML seemed more attractive when your alternatives were Java or, even worse, Objective C. But really both options are…

But we don't want the data and code to be the same, we want the data to be less dynamic than the code. You can't find out what the UI of a Lisp program would be without executing the program. It has everything available all the time, which is bad and turns you into a Lisp weenie.

SwiftUI is using new Swift features sort of similar to Haskell's "do" notation, which isn't actually itself monads.

Re: SwiftUI

#359

Post by vorg » Tue, Jun 04, 2019, 10:01 PM UTC

melling wrote: post #189

there were lots of Swift holdouts. In fact, there has been a resurgence of Objective C Objective C is much higher than Swift: 11 vs 18. https://www.tiobe.com/tiobe-index/ This should reverse the rankings and might push Swift into a top 10 language.

> Objective C is much higher than Swift: 11 vs 18.

And Apache Groovy rose from number 91 to number 17 in the past 12 months also according to that same Tiobe page (May 2019). Quoting Tiobe for anything only discredits what you're trying to prove.

Re: SwiftUI

#360

Post by eugeniub » Tue, Jun 04, 2019, 10:58 PM UTC

ambivalence wrote: post #327

simonh wrote: post #321

Earlier quoted context omitted.

Yep, if your margins are 20% and you lose 10% of your user base and revenue, you just lost half your profit.

I must be missing something here. Assuming on a napkin that all users roughly generate the same amount of revenue, losing 10% of them will lose you 10% of your profit, no? If anything, users of really old iPhones are likely to be less spendy so you're losing less than 10%.

Profit is revenue minus expenses. Supporting more versions of iOS essentually means greater expenses. So the decision to drop support of older iOS versions is basically the questions of whether or not the additional expense of supporting it is greater than the additional revenue those users generate. For a company like Facebook, the revenue is much greater than expense, while for a smaller company, it's probably smaller.