SwiftUI tutorials rewritten completely • Hacker News Board

Re: SwiftUI tutorials rewritten completely

#71

Post by jamil7 » Tue, Dec 15, 2020, 9:21 AM UTC

radiKal07 wrote: post #56

dep_b wrote: post #53

So far dealing with stuff like PayKit SwiftUI integration still feels really bad. There's just tons of stuff expecting UIKit and it will take a while before all of that stuff is ported. SwiftUI is really great, Combine can be hard to get into for people not initiated in Reactive and generally it's as fast to build stuff in as Flutter without dealing with the tragedy called Dart.

What is wrong about Dart? I come from a Kotlin background and I don't see anything wrong with Dart honestly

In my opinion it's not an especially compelling language (yet maybe it evolves into one) and is useless outside of Flutter. It feels shoehorned into the project because Google wanted to find a use for it. It simultaneously alienates mobile developers and cross platform developers by picking a language neither have experience in and neither can use outside of this one framework. There are people taking about Flutter being to Dart what Rails was to Ruby so maybe time will tell. Flutter itself seems decent though, despite a few oddities.

Re: SwiftUI tutorials rewritten completely

#72

Post by jamil7 » Tue, Dec 15, 2020, 9:26 AM UTC

lenkite wrote: post #31

Is SwiftUI just an abstraction over AppKit and UIKit ? Does it bring any widgets of its own - ie something native to SwiftUI as opposed to being wrapped ? (apart from the declarative stuff)

For now, it mostly wraps existing UI frameworks yes. In the future if Apple decides to, they can depreciate AppKit and UIKit without changing the SwiftUI APIs and have it drawing directly. I see that as a very, very long way away though, UIKit/AppKit will be around for years to come.

Re: SwiftUI tutorials rewritten completely

#73

Post by jamil7 » Tue, Dec 15, 2020, 9:34 AM UTC

rubicon33 wrote: post #19

Why learn SwiftUI? If you want a declarative UI framework wouldn’t you be better served for your time to learn something like React Native or Flutter? I’m not trying to knock SwiftUI, I am genuinely curious what the value proposition is for anyone considering it...

There are a lot of reasons and they can be discussed ad-nauseum. When you boil your question down to it's essence: "Why use a first-party framework and language" it's much easier to answer. The simplest and most pragmatic answer is "because this is what Apple tells us to use". It's a business decision more than anything else, if your business somehow depends heavily on mobile then you want to build native apps.

Re: SwiftUI tutorials rewritten completely

#74

Post by bromuro » Tue, Dec 15, 2020, 10:37 AM UTC

socialdemocrat wrote: post #64

nanagojo wrote: post #9

Man I wish Xcode was a decent IDE

Odd, I don’t really like IDEs but I think Xcode is among the least shitty IDEs out there. Too many IDEs have just terrible GUI design.

Same here - I like working with XCode because the native UI!

Re: SwiftUI tutorials rewritten completely

#75

Post by user-the-name » Tue, Dec 15, 2020, 10:38 AM UTC

socialdemocrat wrote: post #64

nanagojo wrote: post #9

Man I wish Xcode was a decent IDE

Odd, I don’t really like IDEs but I think Xcode is among the least shitty IDEs out there. Too many IDEs have just terrible GUI design.

Yeah, Xcode has some annoying bugs occasionally but in terms of UX, it's miles ahead of anything else I've used.

Re: SwiftUI tutorials rewritten completely

#76

Post by user-the-name » Tue, Dec 15, 2020, 10:40 AM UTC

rubicon33 wrote: post #23

amw-zero wrote: post #20

Earlier quoted context omitted.

Because it’s native to the platform. Seriously, that’s huge. The React Native toolchain is cumbersome to say the least. There’s something to say about a first-class library, meaning one that is being used exactly as designed. I mean, why do people use Javascript? Because it’s the native language of the browser.

Yea I don’t disagree, but what development team has the luxury of choosing SwiftUI? Most places hiring are looking for cross platform “2 developers for the price of one” ... and the burden of dealing with cumbersome react native falls on the developer.

Anyone serious about doing high quality apps will do native development on each platform.

Re: SwiftUI tutorials rewritten completely

#77

Post by dep_b » Tue, Dec 15, 2020, 10:42 AM UTC

radiKal07 wrote: post #56

dep_b wrote: post #53

So far dealing with stuff like PayKit SwiftUI integration still feels really bad. There's just tons of stuff expecting UIKit and it will take a while before all of that stuff is ported. SwiftUI is really great, Combine can be hard to get into for people not initiated in Reactive and generally it's as fast to build stuff in as Flutter without dealing with the tragedy called Dart.

What is wrong about Dart? I come from a Kotlin background and I don't see anything wrong with Dart honestly

The compile time guarantees could have been much better, especially around null pointers. Now they're hacking in non-nullability the same broken way they did it in Java. Same goes for a lot of things like switch / case statements requiring breaks but not supporting checks for covering all cases compile time.

In general it just feels like old Java spiced up with some Javascript niceties like Futures and a nice constructor syntax.

But you should've noticed that coming from Kotlin?

Why wouldn't they use Kotlin as most mobile developers are already used to it?

Re: SwiftUI tutorials rewritten completely

#78

Post by user-the-name » Tue, Dec 15, 2020, 10:43 AM UTC

pjmlp wrote: post #47

Razengan wrote: post #43

Earlier quoted context omitted.

After you’ve used SwiftUI you wouldn’t want to work with any other framework. Even with all the rough edges currently SwiftUI+Combine is how I want all my programming to be done from the day they were announced.

You should try to have a go at Smalltalk and commercial Common Lisp environments.

I highly doubt it is even possible in any og those to produce something that would actually be releasable as a high-quality iOS app, rather than an embarrassing, ugly mess.

Re: SwiftUI tutorials rewritten completely

#79

Post by yoz-y » Tue, Dec 15, 2020, 10:43 AM UTC

rubicon33 wrote: post #19

Why learn SwiftUI? If you want a declarative UI framework wouldn’t you be better served for your time to learn something like React Native or Flutter? I’m not trying to knock SwiftUI, I am genuinely curious what the value proposition is for anyone considering it...

If you only target iOS for example it's a no brainer. There are use cases where you absolutely have to use it, those are currently Home Screen widgets and WatchOS Apps + complications. I would not be surprised if more SwiftUI-only use cases were progressively added.

SwiftUI is also cross-platform, in Apple ecosystem. That is, you can develop all of your components and have them work on iOS and macOS. Then glue them together with platform specific main view.

SwiftUI will also always have all of the native features whereas cross-platform tools always lag behind. This is important for smaller developers as releasing before others can be what makes or breaks your app's success.

Re: SwiftUI tutorials rewritten completely

#80

Post by madeofpalk » Tue, Dec 15, 2020, 10:45 AM UTC

wil421 wrote: post #60

vlozko wrote: post #36

Oh wow, I personally know someone who joined the dev pubs team to work on this documentation. I think a big factor in the improvements was their hiring practices. Traditionally Apple has required that employees be on-site. Their dev pubs team is a notable exception and a signify part of that team is remote.

When has Apple traditionally required employees to be on site? I know a few people who have worked remote at Apple for over a decade.

My understanding - as someone who knows nothing but just read tweets - is that hiring strongly prefers on-site, whereas tenured employees are usually able to negotiate remote work.