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

SwiftUI tutorials rewritten completely

developer.apple.com

Post reply on HN
Print view View original

81–90 of 115 posts

Re: SwiftUI tutorials rewritten completely

#81

Post by madeofpalk »

dep_b wrote: post #77
radiKal07 wrote: post #56

Earlier quoted context omitted.

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 constru…

> especially around null pointers. Now they're hacking in non-nullability the same broken way they did it in Java

Typescript was my first introduction to a typed language and it astonishs me the decisions made in the 'earlier days' regarding nullability.

Re: SwiftUI tutorials rewritten completely

#82

Post by ksec »

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.

Apple makes exceptions to exceptional people. I mean, OSX x86 port started with a remote engineer.

Re: SwiftUI tutorials rewritten completely

#83

Post by ksec »

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.

I sometimes wonder why do we continue to get macOS update. Were any of those "user" features really better?

I wish they spend more time looking into Xcode, developer documentation etc. And it is 25M developers at $99 a year. That is $2.5B. And it is looking less than $10M a year investment into Xcode.

Re: SwiftUI tutorials rewritten completely

#84

Post by bsaul »

yoz-y wrote: post #79
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 t…

"cross-platform, in Apple ecosystem". Please, let's not gobble that crappy apple PR spin on what that term means.

Cross-platform never meant "just an iphone and a mac os with the correct version". SwiftUI looks like a very cool tech, but it isn't "cross-platform", period.

Re: SwiftUI tutorials rewritten completely

#86

Post by torarnv »

extraduder_ire wrote: post #58
Austin_Conlon wrote: post #6

Earlier quoted context omitted.

It's been expanding ever since the WWDC 2019 release, same with other newer frameworks like Combine, and it mostly goes unnoticed. They should have some way of showing what docs have been updated, currently in the Apple Developer app I think it only highlights new articles.

>They should have some way of showing what docs have been updated Back when I used wrote iOS crap, I used dash as a quick reference for APIs.That was pretty good at alerting me to documentation changes, since it has to download an update. https://kapeli.com/dash I only started using it (never did buy it) because I was used to using zeal, a free-software alternative. https://zealdocs.org/

I like Dash, I bought it. But unfortunately the version upgrade from 4 to 5 introduced some mandatory UI changes that made documentation lookup much more cumbersome. Looking up a function now takes several user interaction steps, instead of just one in Dash 4. I'm still on version 4. If anyone have alternatives, I'm all ears.

Re: SwiftUI tutorials rewritten completely

#88

Post by ninkendo »

jondwillis wrote: post #39
spideymans wrote: post #17

Earlier quoted context omitted.

The autocomplete and syntax highlighting feature completely stops working sometimes. It’s beyond frustrating

Simply: CMD+, Locations Derived Data CMD+Q Xcode Delete!!! Derived Data Restart Xcode Why not Clean Build Folder CMD+B success!!

I have a shell alias for

  mv ~/Library/Developer/Xcode/DerivedData ~ && rm -rf ~/DerivedData &
And I use it constantly. This approach is fast because it does the actual rm in the background so I can relaunch Xcode right away.

Re: SwiftUI tutorials rewritten completely

#89

Post by ninkendo »

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.

Xcode’s main issues are its bugs (which are inexcusable) and the project file format which is way too hard to work with.

Why aren’t files in groups sorted by default? Why does sorting them cause large sections of the project file to be rewritten? Why do I need to add files through the UI? (Why can’t I create them in the terminal and have them just show up?)

I know that groups vs folder references play a role here but most projects use groups, and groups are a terrible experience.

It all leads to constant merge conflicts and files just accidentally getting removed from groups and nobody being able to tell in code review. They need to fix the project file.

Post reply on HN