5 ms·

True, the APIs are usually top notch, but I really hope SwiftUI will get another revision or something. It looks good on paper, but you constantly run into thin

True, the APIs are usually top notch, but I really hope SwiftUI will get another revision or something. It looks good on paper, but you constantly run into things that are really weird, odd, and feel like hacks. State management is too complicated as well.

throwaway894345 5y ago
I'm curious to hear about people's impressions of Swift the language. I haven't used it, but I'm keeping my eye on it, especially if it ever properly makes the leap out of the Apple ecosystem and into general purpose computing (yes, I'm aware that there are efforts, but to my knowledge none have resulted in many commercially successful applications--i.e., it isn't "mainstream" yet).
- math-dev 5y ago
  I will let others more qualified opine, but for me it was quite easy to use. I think Android has Kotlin, and imo Swift & Kotlin are not too different, which makes it easier for someone trying to build across two different platforms. I like Swift’s use of generics and protocols (can’t remember if I am using the right terms), but I really didn’t like some of the more recent changes that obscured parts of the language behind unnecessarily obtuse DSLs. That said, I think everybody enjoys what they use most, so I don’t see Swift leaving the Apple ecosystem in the near future. These days I have been abducted by aliens, extra terrestrial beings, and program exclusively in Common Lisp, with its secret alien technology. Now THAT is a language I recommend, its simply amazing to me :)
  - throwaway894345 5y ago
    > That said, I think everybody enjoys what they use most, so I don’t see Swift leaving the Apple ecosystem in the near future FWIW I've used Python and C++ the most, and I deeply dislike them. :)
  - kitsunesoba 5y ago
    One of the biggest differences between Swift and Kotlin in my day to day is that breakpoints/debugging in Kotlin are glacially slow compared to the same in Swift (which itself is a fair deal more slow than debugging Objective-C). I'm not sure if this is due to JVM baggage or what, but it can make chasing down bugs in Android rather painful, slowing methods that normally run in a fraction of a second to take several minutes.
- blacktriangle 5y ago
  It's good, but it's not really anything special. It feels like a mixture of the good parts of Scala, Kotlin, and Rust. Unfortunately lately it's getting pulled in a weird direction by SwiftUI (property wrappers and function builders are just unnecessary). It will be interesting to see how their actor implementation plays out. For the most part though it feels very restricted with its need for Obj-C interop and I suspect it will never make the leap out of the Apple ecosystem simply because it doesn't offer enough over the aforementioned languages to be worth the trouble.
  - tictac-toe 5y ago
    > It feels like a mixture of the good parts of Scala, Kotlin, and Rust. Indeed, I think at the moment it's hands down the best language available for general application programming. The problem is the lack of libraries on non-apple platforms.
  - read_if_gay_ 5y ago
    Property wrappers are unnecessary but sometimes they allow for very clean code. For example you can create a wrapper to persist data to UserDefaults like @Persisted(key: “myKey”) var myInt = 42 which is a really nice way to avoid a lot of boilerplate.
- allenu 5y ago
  Speaking purely as someone who was using Objective-C before on Mac and iOS apps, it's incredibly productive. I can convert ideas into code very efficiently as the language allows you to be concise. How it compares to other modern languages, I can't comment on too much.
math-dev 5y ago
The documentation of SwiftUI is poor but I was able to create mostly what I wanted from it, this was a year or so ago. I released a SwiftUI calculator I built earlier as open source on GitHub, it may be useful for some dipping their toes into it. I actually really enjoyed working in SwiftUI. Towards the end of my time, I started moving into a hybrid approach where I would borrow some of the concepts of CSS stylesheets and clearly separate constant parameters used in UX into their own swift files (making it easier to flip between them, eg when going from light mode to dark or from iPhone to iPad) Link: https://github.com/ashok-khanna/RPN-31 https://github.com/ashok-khanna/RPN-31
- read_if_gay_ 5y ago
  > I was able to create mostly what I wanted from it Is "what I wanted" just the calculator app you link? Of course I don't know how much complexity went into it, but maybe the app just didn't touch on the darker corners/pitfalls of SwiftUI that I find you only run into when it comes to Core Data, fancy views, animations/transitions and so on.
  - math-dev 5y ago
    Core Data is a persistent storage facility so can be handled either in Swift or SwiftUI. I wrote a reasonably valued answer on controlling animations in SwiftUI on SO, so I was happy to push the boundaries there: https://stackoverflow.com/questions/58284994/swiftui-how-to-handle-both-tap-long-press-of-button https://stackoverflow.com/questions/58284994/swiftui-how-to-... The app doesn’t have any super advanced animation, but for most apps, I don’t think that is required. But that’s personal opinion. This is a longwinded way of saying perhaps you are right and I haven’t fully appreciated more advanced UI, but at the same time many of the basics in SwiftUI cover many use cases :)
    - read_if_gay_ 5y ago
      > many of the basics in SwiftUI cover many use cases :) Yeah, I fully agree. But I also feel like if your use case isn't covered, you're losing much of the elegance, and I hope that's just because SwiftUI isn't fully mature yet. Sorry if I came across like I just thought your app was too basic. I was just trying to say that you might have happened to not run into any of SwiftUI's rough edges, no offense. Regarding Core Data of course you're right that it's not directly related to SwiftUI but interfacing with it from a SwiftUI app feels very un-SwiftUI-like. I hope they have something in the pipeline for WWDC.
apozem 5y ago
I would love to see more Mac-like views in SwiftUI. When I made my Mac app, I ended up wrapping an NSTableView to get all the Mac-native behaviors not offered by a List.

throwaway894345 5y ago

I'm curious to hear about people's impressions of Swift the language. I haven't used it, but I'm keeping my eye on it, especially if it ever properly makes the leap out of the Apple ecosystem and into general purpose computing (yes, I'm aware that there are efforts, but to my knowledge none have resulted in many commercially successful applications--i.e., it isn't "mainstream" yet).

math-dev 5y ago
I will let others more qualified opine, but for me it was quite easy to use. I think Android has Kotlin, and imo Swift & Kotlin are not too different, which makes it easier for someone trying to build across two different platforms. I like Swift’s use of generics and protocols (can’t remember if I am using the right terms), but I really didn’t like some of the more recent changes that obscured parts of the language behind unnecessarily obtuse DSLs. That said, I think everybody enjoys what they use most, so I don’t see Swift leaving the Apple ecosystem in the near future. These days I have been abducted by aliens, extra terrestrial beings, and program exclusively in Common Lisp, with its secret alien technology. Now THAT is a language I recommend, its simply amazing to me :)
- throwaway894345 5y ago
  > That said, I think everybody enjoys what they use most, so I don’t see Swift leaving the Apple ecosystem in the near future FWIW I've used Python and C++ the most, and I deeply dislike them. :)
- kitsunesoba 5y ago
  One of the biggest differences between Swift and Kotlin in my day to day is that breakpoints/debugging in Kotlin are glacially slow compared to the same in Swift (which itself is a fair deal more slow than debugging Objective-C). I'm not sure if this is due to JVM baggage or what, but it can make chasing down bugs in Android rather painful, slowing methods that normally run in a fraction of a second to take several minutes.
blacktriangle 5y ago
It's good, but it's not really anything special. It feels like a mixture of the good parts of Scala, Kotlin, and Rust. Unfortunately lately it's getting pulled in a weird direction by SwiftUI (property wrappers and function builders are just unnecessary). It will be interesting to see how their actor implementation plays out. For the most part though it feels very restricted with its need for Obj-C interop and I suspect it will never make the leap out of the Apple ecosystem simply because it doesn't offer enough over the aforementioned languages to be worth the trouble.
- tictac-toe 5y ago
  > It feels like a mixture of the good parts of Scala, Kotlin, and Rust. Indeed, I think at the moment it's hands down the best language available for general application programming. The problem is the lack of libraries on non-apple platforms.
- read_if_gay_ 5y ago
  Property wrappers are unnecessary but sometimes they allow for very clean code. For example you can create a wrapper to persist data to UserDefaults like @Persisted(key: “myKey”) var myInt = 42 which is a really nice way to avoid a lot of boilerplate.
allenu 5y ago
Speaking purely as someone who was using Objective-C before on Mac and iOS apps, it's incredibly productive. I can convert ideas into code very efficiently as the language allows you to be concise. How it compares to other modern languages, I can't comment on too much.

math-dev 5y ago

The documentation of SwiftUI is poor but I was able to create mostly what I wanted from it, this was a year or so ago. I released a SwiftUI calculator I built earlier as open source on GitHub, it may be useful for some dipping their toes into it. I actually really enjoyed working in SwiftUI. Towards the end of my time, I started moving into a hybrid approach where I would borrow some of the concepts of CSS stylesheets and clearly separate constant parameters used in UX into their own swift files (making it easier to flip between them, eg when going from light mode to dark or from iPhone to iPad) Link: https://github.com/ashok-khanna/RPN-31 https://github.com/ashok-khanna/RPN-31

read_if_gay_ 5y ago
> I was able to create mostly what I wanted from it Is "what I wanted" just the calculator app you link? Of course I don't know how much complexity went into it, but maybe the app just didn't touch on the darker corners/pitfalls of SwiftUI that I find you only run into when it comes to Core Data, fancy views, animations/transitions and so on.
- math-dev 5y ago
  Core Data is a persistent storage facility so can be handled either in Swift or SwiftUI. I wrote a reasonably valued answer on controlling animations in SwiftUI on SO, so I was happy to push the boundaries there: https://stackoverflow.com/questions/58284994/swiftui-how-to-handle-both-tap-long-press-of-button https://stackoverflow.com/questions/58284994/swiftui-how-to-... The app doesn’t have any super advanced animation, but for most apps, I don’t think that is required. But that’s personal opinion. This is a longwinded way of saying perhaps you are right and I haven’t fully appreciated more advanced UI, but at the same time many of the basics in SwiftUI cover many use cases :)
  - read_if_gay_ 5y ago
    > many of the basics in SwiftUI cover many use cases :) Yeah, I fully agree. But I also feel like if your use case isn't covered, you're losing much of the elegance, and I hope that's just because SwiftUI isn't fully mature yet. Sorry if I came across like I just thought your app was too basic. I was just trying to say that you might have happened to not run into any of SwiftUI's rough edges, no offense. Regarding Core Data of course you're right that it's not directly related to SwiftUI but interfacing with it from a SwiftUI app feels very un-SwiftUI-like. I hope they have something in the pipeline for WWDC.

apozem 5y ago

I would love to see more Mac-like views in SwiftUI. When I made my Mac app, I ended up wrapping an NSTableView to get all the Mac-native behaviors not offered by a List.