Hacker News Reader

I needed to do some development in Swift mid last year. I liked it and would continue to use if it weren’t for the fact that it seems like the only current and useful learning resources are Apples WWDC videos and similar content.

> weren’t for the fact that it seems like the only current and useful learning resources are Apples WWDC videos and similar content

I don't know what you mean by "and similar content" but even though I agree that Apple's own documentation could be a lot better (though it is gradually improving), there is an enormously vibrant and flourishing ecosystem of learning materials at all levels, including people like Paul Hudson's Hacking With Swift (with website, tutorials, videos and books), Sean Allen (with YouTube videos and extensive Teachable tutorial courses), expert and in-depth discussions on SwiftUI from the programmers on pointfree.co, other in-depth resources including weekly video tutorials and books from the amazingly smart Chris Eidhof and Florian Kugler at objc.io, video tutorials and in-depth articles from Bart Jacobs at cocoacasts.com, not to mention the very advanced blog-posts from John Sundell at Swift by Sundell.

There are probably hundreds of other blog-resources - definitely more than I can keep up with on a weekly basis.

So lack of learning resources is definitely not a problem for Swift and SwiftUI if you just use some initiative to find it.

PS: people here often mention raywenderlich.com but my own experience is their content often boils down to "for networking use this external library..."

In the past we would do with Apple's documentation alone, I guess that is the point.

With a side helping of the cocoadev mailing list.

I was going a little more back in time than that.

Hey, I do full time iOS development, there’s tons of great resources, but out of all of them my favorite is https://hackingwithswift.com

This is pretty cool, thanks.

Coming from Java and C++, I once wanted to fix a bug in a macOS app written in Swift that used my C++ library. It was a rather frustrating experience because none of my existing knowledge worked. I could see the field I needed in the object in the debugger, but for the life of me couldn't figure out how to get it. It turns out (had to ask the developer who wrote this) I had to write some really weird `if let ...` thing that would extract those fields into local variables that I could then use. Also, immutable everything by default. You can't overwrite function arguments within the function itself, like you could in Java and C++. And unwrap, unwrap, unwrap, unwrap, unwrap everything.

And yes, versions, as you said. I don't like moving targets. I enjoy stability. Java changes, but it at least does so carefully and doesn't drop features (but does sometimes drop obscure parts of the standard library). You can usually compile and run Java 6 code unchanged with JDK 17 just fine.

I like it when there's a clear line between the language itself and its standard library. Swift doesn't have one, neither does Kotlin.

>It was a rather frustrating experience because none of my existing knowledge worked.

Well, it is a new language

>I could see the field I needed in the object in the debugger, but for the life of me couldn't figure out how to get it.

I would need more context to help you out here. You had SomeObject with a child SomeChild and couldn't do

let a= SomeObject.SomeChild ? Perhaps I'm misunderstanding.

>I had to write some really weird `if let ...` thing that would extract those fields into local variables that I could then use.

Sounds like this is importing from some file or something, and whoever wrote the code below you just made everything optional and chucked all the responsibility for that up the chain. I'd have to see the code but it sounds like bad design.

>Also, immutable everything by default. You can't overwrite function arguments within the function itself, like you could in Java and C++. And unwrap, unwrap, unwrap, unwrap, unwrap everything.

That's a feature not a bug. Maybe I'm misunderstanding you, but if you have

func twoStrings(a: String, b: String) -> String, _why on earth_ would you ever want to be able to override that func's params and feed it something else? a/b would be a completely unexpected type and blow up/fail to compile. If you're routinely needing to do this, you haven't embraced static typing I think. Swift Generics are a potential option.

> I'd have to see the code but it sounds like bad design.

I think that dev called that "enum case with parameters" or something similar. Don't really remember at this point.

> _why on earth_ would you ever want to be able to override that func's params and feed it something else?

No, I meant overwriting function arguments within the function itself to avoid rewriting the code below that point. I do sometimes do that in Java and I find it a sensible thing to do. For example

    public String doSomethingWithTwoStrings(String a, String b){
        if(some condition){
            a=something else;
        }
        // do something with (possibly overwritten above) a and b
        return result;
    }

I'm used to treating function parameters as pre-populated local variables. Swift compiler gets in the way and doesn't let me do that because immutability. Comparing with Java, it's as if everything is `final` by default.

> enum case with parameters Ah, this is a language feature of enums in Swift. Swift enums allow you to keep associated values with a specific case and you need to unpack them with a `let` when dealing with that value.

E.g.

  enum Animal {
   case lion
   case tiger
   case bear
   case ohMy(Int)
  }

The case `ohMy(Int)` means that it has an associated value so when you want to get at it from a variable, say:

  var a:Animal

  switch a {
   case .ohMy(let value):
      // do something with `value`
   ...
  }

Ah, I see what you mean. Thanks for the explanation.

This is just my opinion but doing that seems to be very dangerous. You're probably fine for small functions with single-developers, but once you get complex and have multiple people working on the code it seems easy for one dev to confuse another.

If you insist on that pattern (lets call it the local variable method) you can define vars such as

var localA = a

var localB = b

at the top of the function and work on it there. Personally I prefer function arguments to be immutable, so that any time you call them you know what you're working on is what the function was given. Forcing you to declare a local var makes the code much more explicit and easy for another human to reason about what you're doing, whereas they could very easily miss an "a=something else".

I think you should RTFM before jumping in and trying to code by guessing the language semantics. All of these things you dislike are easily achieved by a small change in keyword or function signature.

There's no clear line between language and standard library in C++ or in Java.

The only documentation that’s more frustrating than Apple’s “‘doYouReallyWantThat’ is an attribute. It returns ‘true’ if you really want that. We can’t tell you what’that’ means. Code samples are for lesser people” is Python, where I somehow, every time I want to look up if it’s ‘subst’ or ‘substring’, I somehow end up in either the C bindings or some ten-year old PEP on package management that was never implemented.

PHP in the late 90s did it right (and probably still does today), ruby gets it mostly right, although it, like python, somehow still hasn’t figured out how to get Google to rank the most recent version higher than the one that’s a decade out of date.

The popularity of video tutorials is baffling. Is it because it’s the only way to earn money with this content? Anyway, I’ll just add the observation that the three communities that seem to really embrace the format are QAnon, “men’s right’s”, and WordPress.

It's odd because when iOS development was new the docs and HIG were very comprehensive. Almost every answer regarding iOS on places like StackOverflow would be "here's a link to that part of the docs". They also had a lot of good examples.

And now they’re gradually making those old docs unreachable. I don’t know what Apple’s endgame is here, but it’s pretty sad.

Those of us that are old dogs can still find most of them on the archive, because we know kind of what to search for, but even those might disapeer one day.

Horizontal stack control - https://www.appcoda.com/learnswiftui/swiftui-gridlayout.html

Is that what you need?

This isn’t exactly what I was looking for - basically I wanted an HGrid with a bunch of items that would automatically wrap rather than overflow. (In the WPF world that I’m more accustomed to this would be called a “WrapPanel”).

I eventually found a package on GitHub called WrappingHStack that did exactly what I needed but this struck me as odd that something like this wasn’t out of the box functionality.

Ahh I see. I would agree, still a lot of missing components.

>Swift itself is also quite nice - although it’s evolving really, really fast and tutorials/howtos and such go stale really quickly. Swift can and will drop language feature at the drop of a hat. Just today I wanted to do a simple C++ style for loop only to find this was removed completely from the language.

What are you talking about? Swift has had (and still has) basic for loops since 1.0. What am I missing here?

Details: https://github.com/apple/swift-evolution/blob/main/proposals...

There were plenty of alternative ways to accomplish my scenario but they ended up being pretty clunky and overly expressive for what I was trying to do at the time.

It seems like the Swift language designers have no qualms about removing language features and breaking old code as a result - which is certainly their prerogative but it’s not something I’m accustomed to.

Wait, is this some kind of a joke? That's swift evolution number *seven*. They're on hundreds now. That was committed in 2015. This is what, Swift 1.x days? Before?

What production code was even using swift back then? The vast majority of people didn't _start_ using swift until 3.x.

I know we're supposed to take the best-possible interpretation of someone's comments here, and in my opinion a joke is the best possible take on the above post. The alternative is you're being disingenuous.

Not sure where these accusations are coming coming from but no joke or disingenuousness was intended here. You replied to my comment originally and I answered your question with more details.

I’ve said before that Swift is a relatively new language to me. I’m not up to date on its many “evolutions” or particularly familiar with its history and nuances. I am not even sure what Swift version I’m on right now other than “whatever the latest version of Xcode uses”. I’m just trying to learn the Swift/SwiftUI stack by writing some code for MacOS and iOS as part of a hobbyist project that I’m working on during my downtime.

When I was trying to do something that’s worked fine in many other languages the Swift compiler literally told me “no” because it had been removed from the language in version X. I mean whatever - I found how to work around this - it was a kind of clunky and overwrought one versus the simplicity of the original code but it met my needs and it was a teachable moment.

My overarching point originally wasn’t meant as a hard criticism of Swift. I’m fact I quite like it. It was an observation that Swift is unlike other languages I work with regularly where it’s rare that language features are ever removed (or at worst hidden behind compiler or feature flags).

Swift’s designers clearly think it’s ok to remove things they don’t like or they don’t think meets their vision. That’s fine and valid. My point was that as a result of this stance that means tutorials and samples can become stale in a way that I don’t see with the other languages I work with where you’re more likely to be using old methodologies or obsolete APIs - that can/should emit compiler warnings or IDE refactor hints - but otherwise won’t fail to compile because something was removed completely.

> Swift itself is also quite nice - although it’s evolving really, really fast

Coming from C# you should feel right at home (though the documentation seems better).

If I compare the C# code I was writing 12 years ago to the current one, it feels like 2 different languages.

I think the primary difference is while C# evolves, old language features don’t just get removed. Old code samples will still work even if they aren’t “modern” or optimal solutions anymore.

For contrast, Swift will drop support for features that can render old code samples useless. I’ve written code fails to compile with an error literally saying what I am trying to do was removed from the language in version X. Things like that can be aggravating for a newbie like me to deal with.