Hacker News new | comments | show | ask | jobs | submit login

It would be helpful if Apple did a review of the sample code in the developer's library and fix all the software that won't even compile anymore. It doesn't help people trying to learn this language if the sample code won't work.



+1 I'd also make a humble suggestion to have a dedicated sample code person who's well versed in Swift, to make the sample code consistent and well documented.

To have sample code for every new feature, etc. This should not be a coop or someone doing it in hindsight - the number of hours people spend re-inventing how to do infinite scrolling tableviews (one simple example) is sad - every new developer has to re-invent the wheel it seems.

This leads to people using third party libraries for things that need no libraries at all, and then before you know it, you're swimming in cocoapod soup, every time you join a new project, and the soup is 50% new ingredients every other time too!


> a dedicated sample code person who's well versed in Swift, to make the sample code consistent and well documented

I’m pretty sure they have multiple people with a role like this (I know they have one at least, since I’ve met him).


Yeah, Apple's developer documentation is definitely subpar. They don't maintain the samples well (if there are any) and they are a bit on the lazy side when it comes to documenting class methods and variables. Sometimes they just tell you that something exists.


> Swift 4.1 is a minor language release. It is source compatible with Swift 4.0.

Nothing should break?


A lot of sample code is still Swift 1 or 2 code, which is not source compatible.


Am I the only one who finds the rapid source incompatibilities problematic? Like maybe a language shouldn’t move so fast or be better nailed down before production.


You have two choices: bake the language fully before release, or push out what you have and get the community involved.

I’d argue the second option is almost universally better.


Reasoning about effect aside, I walked away from an iOS project (personal) primarily because the language moved so fast it lot me.


Swift changed less between 3 and 4 than between 1.0 and 1.1.

The last two years or so have been fine for me.


I would say that a lot of people jumped on board with Swift before it should really have been used so widely. Objective C was - and still is! - a totally acceptable way to build an app for iOS.


You could do it Objective-C.


I don't think you're the only one.

Steve Troughton-Smith, Michael Lauer, Dan Leivers, Peter Molnar, Todd Thomas, Ian McDowell, Simon Wolf, Marco Arment all didn't seem (2017-10-04) in a particular hurry to adopt Swift. [0]

https://www.hackingwithswift.com/articles/27/why-many-develo...


I feel most of the developers there more more unhappy about the lack of ABI stability, poor tooling, and learning a new language than the constant changes that Swift has.


Fair point, that's more precise. You're clearly better informed than me.

The following quote from Steve Troughton-Smith in the article that I linked was enough for me - I'm not going to beta test Swift for Apple either.

>I'm not yet convinced of Apple's level of participation in the language — four years on, Swift is not used for important pieces of iOS, OS or frameworks (I maintain a running list of Swift apps from Apple on Twitter, and macOS is definitely less shy about adopting it for new features than iOS). I understand why that is the case (ABI stability, etc), but if Apple's not using it for everything I don't see why I need to be beta-testing on their behalf. I lose nothing from waiting until Swift is 'ready', and I gain all the benefits of Objective-C in the meantime.


Apple has actually gotten quite good at adopting Swift for new projects where ABI stability is not an issue. Off the top of my head, Picture-in-Picture, Dock, and Touch Bar on macOS, and Calculator and parts of the WWDC app on iOS are mostly Swift. New developer tools, such as Playgrounds and parts of Xcode are Swift as well. Of course, you’ll notice that none of the uses I mentioned were core frameworks, since these are places where Apple cannot use Swift code.


launchd is also written in Swift now.


Huh, I wasn't aware of that. Are you sure? launchd doesn't seem to link against any Swift libraries:

  $ otool -L `which launchd`
  /sbin/launchd:
  	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)
  	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
  	/usr/lib/libauditd.0.dylib (compatibility version 1.0.0, current version 1.0.0)
  	/usr/lib/libbsm.0.dylib (compatibility version 1.0.0, current version 1.0.0)
  	/usr/lib/libdz.dylib (compatibility version 1.0.0, current version 110.50.29)


That was part of the message at WWDC 2017, Dock and launchd ported to Swift.

I guess we can go through the videos to track down where it was communicated.


Like another commenter has mentioned, Swift is now almost nearly source compatible. The compiler already provides support for any version of Swift back to version 3.2.


Unfortunately, if what others here are stating is true, many of the examples date to Switch version 1 and 2...


> others

You might want to check the username on that comment ;)


LOL. I was actually referring to your specifics and protomyth's general statements about much of it not compiling, but it's obvious you are familiar with whatever the situation is. :)


Getting it out to be used by as many devs as possible is also a valid way of "nailing gown".


Go to the Apple developer page of sample code https://developer.apple.com/library/content/navigation/#sect... and see how much actually compiles, its not a lot.


I saw a couple regressions, but I believe that was the goal




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: