Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
I assume you mean from UIKit to SwiftUI, and not from Swift to SwiftUI :p

I’m still more familiar with UIKit so I’ll still use it, but I do more and more in SwiftUI - I don’t think it’s something (yet at least) you switch over to entirely, but more something you might merge into a UIKit based app. I mean if you start a new project you might do it more or less entirely in SwiftUI, bot for existing projects I don’t see a need to move over entirely at this point, but more just have some screens done in SwiftUI. It’s quite a nice framework for modularity since it’s better at keeping related code packed together in one place than traditional methods of using UIKit. But when interacting with other system parts like the SceneDelegate you’ll still have to interface with UIKit anyway, so a hybrid approach makes good sense. - The latest episode of Swift By Sundell actually has a lot of talk about this exact thing, whether SwiftUI is fully production ready and good use cases for it regardless of whether one thinks it’s ready for large enterprise rollouts or not.

ANything in particular you’re having difficulties with? Are you following along with Apple’s guide? I found it an absolutely excellent interactive guide/documentation
 
Sorry for the confusion, I should have said UIKit :)

I'm slowly learning SwiftUI while still working with UIKit. I'm experimenting SwiftUI and try to get used to the new language.

Yes, I listen to Swift by Sundell and few others podcasts.

I also follow the Apple's guides. Very interesting and perfect to learn things the good way.


My main goal of learning SwiftUI is to release an all-new version of one of my apps.
 
  • Like
Reactions: CheatSheet
I honestly found it a really intuitive API to work with - Though I also haven’t converted super complex views to SwiftUI, only the smaller and simpler ones

No need to adopt SwiftUI if You prefer just working with UIKit though. Good to learn of course, but if you’re comfortable with your UIKit codebase, it’s fine to just stick with that
 
  • Like
Reactions: throAU
I want to learn SwiftUI because I'm far from being a UIKit expert and I prefer investing time in the new stuff. This is why my new apps will be in SwiftUI and I'll maintain my old ones in UIKit.
 
I’m new here and I already like the place 👍

Yeah, MacRumors is great! I’m a bit of a veteran here. There are a lot of amazing people on the forums and you quickly start recognizing some key names. Lots of great communities. Though of course like anywhere there are also dumb, rude and rubbish posts, but the mods do a pretty good job cleaning the spam and such quickly when that does come in, and restrictions on political posts (needing to have posted a certain number of times before you can post on political subjects), help keep trolls out of that space. Front page articles can get a bit hectic and overly negative at times, but the less frequented parts of the forum are always super lovely and the main blogs usually are nice too.
MacRumors is a great source for anything new Apple, and the forums on here are great! Especially the geekier ones.
Of course it’s not StackExchange so for code specific questions, you might often want to also post on Stack, since the majority of people on here aren’t programmers and the ones that are might not see the post, but there is definitely also an active developer community on here.
Personally I’ve got email notifications set up for the Developer forums and often look at the “New Threads” from all forums and just jump into anything that strikes me as interesting, or where I feel I might be able to provide qualified or unique help

Welcome onboard :)
 
I know, I've ran a forum for many years :)

I'm not here for code questions, just to meet new devs and talk about anything except coding :)

Thanks for the welcome !
 
SwiftUI doesn't seem ready for prime time right now, but might become so after WWDC. More tutorials might become available after that. So I'd wait a few months to decide, and just play with UIKit til then.
 
SwiftUI doesn't seem ready for prime time right now, but might become so after WWDC. More tutorials might become available after that. So I'd wait a few months to decide, and just play with UIKit til then.

I think that depends on your application. I am building something new in SwiftUI now. So far I've not found anything that's impossible. And very little that requires dropping out to UIKit. There are some glaring missing items (no colour picker!) but it's surprisingly well formed for v1. I do wish the compiler errors on complex views were clearer though
 
  • Like
Reactions: MisterSavage
I think that depends on your application. I am building something new in SwiftUI now. So far I've not found anything that's impossible. And very little that requires dropping out to UIKit. There are some glaring missing items (no colour picker!) but it's surprisingly well formed for v1. I do wish the compiler errors on complex views were clearer though

Did you try it back with the Xcode beta it originally was introduced with? The error messages back then were so incredibly broken that it would actually show errors on lines without any issues most the time. Even had it complain that "import SwiftUI" wasn't valid. Change something somewhere else and the error would morph or disappear. - It's improved a damn lot from that, but yeah could still use a lot of work
 
This would be my biggest complaint. Errors can show up on a line that is nowhere near where the line with the actual problem is. Has confused me more than once.

They still do that for you? Haven't had that happen much since the beta period for Catalina ended, but then again I've also mostly still used UIKit
 
I never had the “pleasure” of the beta. I too still see errors on weird lines. Frequently an error anywhere in the view causes an error on the var body : some View line. Most often this is when you have a typo in a binding variable name for example.
 
  • Like
Reactions: MisterSavage
They still do that for you? Haven't had that happen much since the beta period for Catalina ended, but then again I've also mostly still used UIKit

Unfortunately yes.

I never had the “pleasure” of the beta. I too still see errors on weird lines. Frequently an error anywhere in the view causes an error on the var body : some View line. Most often this is when you have a typo in a binding variable name for example.

Exactly! The error was reported at the top of body. Turns out using the $0 in an inner closure was ambiguous with the other code I had.
 
What I'm missing is the road map. I don't know where Apple are going with app design & screen design so I don't know if I should commit any time to SwiftUI. It doesn't do everything and until it's obviously 'the future' I won't commit.
 
  • Like
Reactions: atmenterprises
To answer the OP's question, yes I found it very hard initially to wrap my head around it. With UIKit it felt like what I'm used to with programming where you list the steps you want the app to take (animate this, disable this, then present this view). Controlling the UI through state changes with SwiftUI was brain bending at first.
 
So I've hit one of those annoying SwiftUI problems. And this one, for now, I can't seem to resolve. If I navigate to a specific view/view state in landscape mode the app crashes. Same navigation in portrait works. Rotating from portrait to landscape on that view also works. The view in question has a state object associated with it and depending on the state displays one other view (basically a big switch statement: a routing view). If I replace the view being displayed with Text("Test") all is fine. So it's something in that view but I can't work out what! The debugger/error message is, as expected with Swift UI, useless!

Console shows:
Code:
2020-06-05 12:57:14.415590+0100 <app name redacted>[4252:229727] precondition failure: attribute failed to set an initial value: 359

Debugger never seems to load!


Ha! Fixed it.

Instead of this:

Code:
GeometryReader{ screen in
…
if screen.size.width > screen.size.height

this does not crash and has the same intended result

Code:
return GeometryReader{ screen in
...
if !self.orientation.isPortrait {

orientation is an ObservableObject from the environment that tracks orientation changes. Note I still need the GeometryReader to get the safe area insets (which does not crash)
 
Last edited:
So I've hit one of those annoying SwiftUI problems. And this one, for now, I can't seem to resolve. If I navigate to a specific view/view state in landscape mode the app crashes. Same navigation in portrait works. Rotating from portrait to landscape on that view also works. The view in question has a state object associated with it and depending on the state displays one other view (basically a big switch statement: a routing view). If I replace the view being displayed with Text("Test") all is fine. So it's something in that view but I can't work out what! The debugger/error message is, as expected with Swift UI, useless!

Console shows:
Code:
2020-06-05 12:57:14.415590+0100 <app name redacted>[4252:229727] precondition failure: attribute failed to set an initial value: 359

Debugger never seems to load!


Ha! Fixed it.

Instead of this:

Code:
GeometryReader{ screen in
…
if screen.size.width > screen.size.height

this does not crash and has the same intended result

Code:
return GeometryReader{ screen in
...
if !self.orientation.isPortrait {

orientation is an ObservableObject from the environment that tracks orientation changes. Note I still need the GeometryReader to get the safe area insets (which does not crash)

Wow that was a good call on how to fix it. They both seem like the same thing!
 
Wow that was a good call on how to fix it. They both seem like the same thing!

Old-school debugging required: comment out almost the whole view then start adding bits back in until you find a block that crashes. Then try and narrow down that block to the specific line. Needing to do this sort of debugging is the biggest problem with SwiftUI today
 
I get SwiftUI not being event driven etc. I always hated coding a view though. Moreover it seems a noob will have a pretty hard time grasping what is going on. So many closures...
 
I get SwiftUI not being event driven etc. I always hated coding a view though. Moreover it seems a noob will have a pretty hard time grasping what is going on. So many closures...

Hm. On the contrary, I actually think SwiftUI is easier for newcomers to learn. That is, people who are entirely new to programming and programming UI specifically. If you already have experience with "traditional" frameworks, probably not, but if you've never tried anything else, I think SwiftUI can be a good place to start. It's much easier to to understand

Button(titleOnButton) {
Behaviour
}

than it is

let b = UIButton(frame: CGRect(width: 100, height: 100)
b.setTitle("ButtonTitle")
b.addAction(self, action: #Selector(method), state: .touchUpInside)
view.addSubview(b)

// Code written from the top of my head and is not at all checked
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.