Swift and SwiftUI thought from a Xojo developer

Swift
1

Hi all,

I thought I’d jot down a few of my thoughts about Swift and SwiftUI as a long time Xojo developer.

I’m less disheartened by Xojo than some on this forum but I have an idea for an iPhone app and I haven’t found the process of developing it with Xojo very easy. It is an entirely new platform and as such basically means I have to learn the framework from scratch. Since that’s the case I figured I might as well use the official tools and see how it goes.

As a prelude to this, I recently ported a VM-based scripting language that I originally wrote in Xojo to Swift as an exercise to learn Swift. I really enjoyed using the Swift language and Xcode (whilst really complex) is pretty nice. The process of porting was dead easy and the scripting language is faster than the Xojo implementation (not by much but the code is easier to refactor).

I’m working through the Apple SwiftUI tutorial which is very comprehensive. I have to say that I kinda like SwiftUI. I’m still struggling to get my head around property wrappers (like @State, @Binding, @ObservableObject, etc) but getting a native good looking view hierarchy up and running is a lot easier than it is with Xojo.

I think I’m going to stick with the tutorial and then try an implement my app idea in SwiftUI. I have to say, I would be a little worried if I was Xojo with their current iOS offering.

5 Likes
2

I’ve been enjoying SwiftUI. Its a little hard retraining to use the SwiftUI paradigm, but I’m getting there…

I also really really appreciate the shear number of people who’re using Swift and SwiftUI, on every single Social Media I’m on, there’s plenty of people who I can throw out a question and get responses back.

Not to mention bucket loads of documentation, for almost everything… except some of the nitty gritty stuff I find myself in. At least now, however I can ask in the Apple Developer Forums and get actual working code.

Lastly… My current SwiftUI app is 3mb (UB), the Xojo version was 18mb, for Intel alone. This to me a huge difference. If I recompile the Xojo app as UB, that’s gonna be a whopping 36mb, versus 3mb…

Not just iOS, Mac, iPadOS, Android (via Skip tools), iOS, watchOS & tvOS from a single project… I’m hoping that Windows will come one day (you can already make Windows & Linux command line apps with Swift…).

2 Likes
3

You’re not alone. Here’s a good presentation from WWDC23 that helped me a lot:

Discover Observation in SwiftUI

2 Likes
4

I forgot about some other things that I really LOVE about Swift.

  1. Concurrency built-in, and so far all my toes are still attached. Xcode will even advise you which functions are slow and should be run on a different thread to prevent UI lockup. Then it will advise you when you’re trying to update the UI from a thread. You can even pick and choose which cores (efficiency or performance) to run the threads on. In the case of the app I’m working on, they’re so fast already, that I’m pushing everything to the efficiency cores to save energy.

  2. Helper apps. There’s a tutorial on how to configure your Xcode project so that it will build your main project and helpers at the same time. Again in code you can choose which processor core to run these on and the best bit, so far I’ve yet to build that’s larger than 200kb, a fully code signed universal binary command line tool. The smallest one I could build in Xojo was 14mb. It is so small that it’'s often done its job and returned way before the Xojo one has finished launching.

  3. Document based applications, I so wanted these in Xojo and in 2015 Geoff even said it was something they should do. Apart from your document logic code, you write the code to open and save the contents (and you’re gonna love how serialization works in Swift), the OS handles open, save, recent items, auto save, versions etc etc all automatically for you.

  4. AppStorage…

  5. SwiftData is exciting.

Now there’s some stuff that I really dislike too.

  1. SwiftUI is still very much in its infancy, and Apple rabid pace of change, means that I have a ton of if thisOSVersion, do this else code everywhere.
  2. Regarding the above it took me a little while to figure out how to make different View modifiers for different versions of the OS.
  3. Trying to decide if I should use structs or classes, although that appears to be getting clearer over time, I think…
  4. I should be getting used to everything in one file, but I’m not. Right now, I’m throwing complex methods in separate files and tying them to the classes with “extension”.

My understanding of @State is that you’re declaring this view owns this property. When it changes, update this view.
@Binding is a way of passing a property from a parent view, in a way that if the child modifies it, the parent is aware of it and will update other views that use it.
@Observable… This one the principle is simple, it’s a class that declares certain (@Published) properties to be observable. When a view uses one of these properties, they’re auto updated if the property changes.
it can feel even more messy when you can store properties in the environment and they’re then passed down the view hierarchy.
And Apple is overhauling @Observeable with macOS 14.

But finally… I’m really happy that you’re experimenting with SwiftUI, I hope that you’ll grow to love it like me, albeit I’m still in the honeymoon period as its only been a couple of months.

2 Likes
5

Unless there is some REALLY BIG fundamental differences between Swift and SwiftUI

  1. I agree 100% which is why I have decided to NOT go the SwiftUI direction (yet)
  2. 99% of the time there should be little to no differences in a Viewcontroller, and those that are required are easily handled with #if os(iOS) ....#endif constructs
  3. This is more “gray” than Xojo, as in Swift a STRUCT can have functions (heck so can an ENUM)
  4. “everything in one file”… WHY? I put each Viewcontroller in its own file, each CLASS in its own file, etc. Makes it easier to organize, and to reuse code in other future projects. I even have a Swift Package I developed that has wrappers for “Xojo like” syntax, and it alone is 55 files, (but only ONE reference in any project that uses that Package)
6

I don’t know how SwiftUI’s view modifiers compare to AppKit/UIKit View controllers. I’ll try better to explain what I mean. I wanted to make the Text views (static text) selectable. The modifier for this “.textSelection(.enabled)”.

But it is only supported on macOS 12 or above, and I’m targeting macOS 11, Xcode will tell me this, but wants me to place the entire view in a #available(macOS 12.0, *) wrapper, not just the modifier.

It took me a long time to realize how I can solve it and my GoogleFu musta been bad, because I couldn’t find other solutions than to duplicate the entire view.

extension View {
 func makeSelectable() -> some View {
        if #available(macOS 12.0, *) { return textSelection(.enabled) }
         else { return self }
    }
}

I’m still not 100% sure I fully understand the difference. I’ve started to use structs mainly for data and classes as controllers of that data.

I didn’t quite explain myself. I’m so used to Xojo focusing the code editor on a certain method rather than being able to see the entire object in one go. Like I mentioned, I’ve started to utilize “extension” to break out complex functions into separate files to make 'em easier to work with for me anyway.

1 Like
7

Thank you for the feedback and encouragement guys.

Whilst most of my Xojo projects have notionally been cross-platform I really only use iOS and macOS platforms myself and since I only code for a hobby I’m happy to leave Windows behind if that’s the sacrifice required to use Swift.

@samRowlands your explanation of @State and the other property wrappers is very helpful thanks.

As for when to use structs and when to use classes, I struggled with this for a while too when I was porting Objo to Swift. I think best practice is to always use a Struct unless you mutate a lot of the object’s properties.

1 Like
9

[quote=“psb87, post:8, topic:3754, full:true”]
I agree with everything that’s been said above, regarding Swift and SwiftUI.
I poked a toe in the SwiftUI pool but decided to hold off diving in just yet because:

  1. The vast majority of what I do is for desktop
  2. I’m much more comfortable with UIKit (and the straight Swift paradigm)

Eventually, though…