Few Swift Language Aggrevations

Question

Created Jun ’23

Replies 2

Boosts 0

Participants 2

Hey Folks,

So I'm coming from 15 years in other languages, primarily Microsoft & open sourced web stacks & embedded c. Swift is pretty cool, I can definitely do some stuff a bit easier in it than others, but I got a few issues I'd really like to see in the next version of it.

Please co-ordinate and Unify simple behaviors.
- For example: Spacer() in an HStack not in a .toolbar separates things but I you put it in a .toolbar it doesn't. It makes it hard to just code without reference up because things behave slightly differently depending on the exact context they are in. HTML is not like this, it just does what you tell it no matter where it is. Also, decide on ForEach or List. Why do I need two iterators which iterate an object with the same syntax that I compose views inside of? So yeah, just that general train of thought across the entire language please.
Please simplify data-binding
- Just look at the sheer number of articles on how to remove an item from an array bound to a swiftUI component.
- I've got structs & classes. Do I really need both? It's like ya'll went half functional and half object oriented. What's frustrating a bit is that the SDKs built on top do not conform equally to either of them.

I'm about halfway into my first iPhone native app dev experience, so I'll probably be back with more. Maybe this is how swift is just done and I should have gone with the other language choice ya'll have, Xcode I think?

Boost

Answer 1

drcrook1 OP

Jun ’23

Oh I forgot a few more.

The simulator and the preview I do not believe run on the same emulator. I get different behaviors from them quite significantly (not like the ones you think of like just navigation stacks and such, but actual behaviors that you would expect to be the same occasionally are not the same). I'm not getting it right now but it happens, so I've been using the actual simulator as my source of true behavior expected and I hope thats right, but it would generally be nice if they were the same and I didn't have to pray I'm coding against the correct emulator.
Item 2

0

Answer 2

Claude31 OP

Jun ’23

For binding (I suppose you refer to SwiftUI here) have a look at recent announcements in WWDC with @Observable. They should simplify it considerably.

For class vs struct, there are a lot of things you can do with struct, but classes offer more flexibility.

This is precisely described in https://docs.swift.org/swift-book/documentation/the-swift-programming-language/classesandstructures/

Structures and classes in Swift have many things in common. Both can:

Define properties to store values
Define methods to provide functionality
Define subscripts to provide access to their values using subscript syntax
Define initializers to set up their initial state
Be extended to expand their functionality beyond a default implementation
Conform to protocols to provide standard functionality of a certain kind
For more information, see Properties, Methods, Subscripts, Initialization, Extensions, and Protocols.
Classes have additional capabilities that structures don’t have:

Inheritance enables one class to inherit the characteristics of another.

Type casting enables you to check and interpret the type of a class instance at runtime.
Deinitializers enable an instance of a class to free up any resources it has assigned.
Reference counting allows more than one reference to a class instance.
For more information, see Inheritance, Type Casting, Deinitialization, and Automatic Reference Counting.

The additional capabilities that classes support come at the cost of increased complexity. As a general guideline, prefer structures because they’re easier to reason about, and use classes when they’re appropriate or necessary. In practice, this means most of the custom types you define will be structures and enumerations. For a more detailed comparison, see Choosing Between Structures and Classes.

I personally do not use Preview as a simulator, but as a tool to design UI (in SwiftUI, positioning the objects exactly where you want is a bit tricky). That's one reason why I still prefer UIKit over SwiftUI.

But for testing, I do use simulator.

0