iOS Switch to SwiftUI?

[casperes1996]

Not coding it also beautiful separated the V in MVC

Except Apple's UIKit really isn't designed for standard MVC. I mean, it's kinda in the name. The controller class isn't just a controller; It's a ViewController. And it typically also handles transition to other controllers so it needs to now not just about itself but other classes as well, so unless you use the coordinator pattern it quickly becomes highly conjoined code.

Sure if you coded it
You also could use IB and control drag

I mean yes, but you can also drag out views in SwiftUI with the View Library. Although you can't place it as freely.

But like, maybe I just suck at IB, but who hasn't had a near endless array of issues with getting IB to be happy with your constraints? And it never bloody tells you why it's not satisfied with your constraints. I may be insane but I feel like when I set up the exact same constraints in code, it's fine, if I do it in IB it complains. Maybe I just don't know how to IB properly

 

[MisterSavage]

Hm. On the contrary, I actually think SwiftUI is easier for newcomers to learn.

Agree 100%. Things such as creating a List are almost trivial now. Using Spacers and padding is drastically more pleasant (to me) for moving UI elements around. I do not miss constraints or storyboard at all.

 

[grandM]

As for the constraints it takes time to master them.
MVC. I agree separation is not perfect. But should it? Over the years I notice a strive towards company code. Yes, it is more organized and maintainable using some patterns. Yes in time a dev should reach that level. However trying to reach this level too soon will toss people aside in a sector already coping to find sufficiently qualified people. Moreover I am sure many apps are not perfectly code. They are out there, making people a living.

You say SwiftUI is easier to learn. It is not. Try explaining to a noob to get Hello world onto a View. You can not. Sure you can say place Text("Hello world) between these brackets. The student does not understand the surrounding code. Building a simple view requires a thorough understanding of protocols, closures and so on. It creates a hurdle too soon. Some will take it, many will not. I have not run into the dragging part yet watching the Stanford course. Glad it is possible. Must linking gesture behaviors be coded?

Don't get me wrong. You obviously are good at coding. I just think it will toughen the experience for many.

 

[casperes1996]

MVC. I agree separation is not perfect. But should it? Over the years I notice a strive towards company code. Yes, it is more organized and maintainable using some patterns. Yes in time a dev should reach that level. However trying to reach this level too soon will toss people aside in a sector already coping to find sufficiently qualified people. Moreover I am sure many apps are not perfectly code. They are out there, making people a living.

To a learner it's completely irrelevant, yeah. But you said it beautifully separates the V in MVC so I wanted to counterpoint that; While I like UIKit, it's not a great example of textbook MVC. So if you are learning about MVC, the UIKit templates and methodology slightly fights you, with it's own spin on MVC or as I call Apple's system, MVVCS (Model, View, ViewController-Segue)
That is not to say that UIKit's way of doing things can't be great too. It's just not textbook MVC

But sometimes textbook way of doing things aren't the best either. Like Kevlin Henney I am often opposed to Singletons for example - At least in Swift. And by that I mean the classic way of doing singletons.
class Object {
static let instance Object()
}
is fine (simplified, remember to privatise constructor too)

You say SwiftUI is easier to learn. It is not. Try explaining to a noob to get Hello world onto a View. You can not. Sure you can say place Text("Hello world) between these brackets. The student does not understand the surrounding code. Building a simple view requires a thorough understanding of protocols, closures and so on. It creates a hurdle too soon. Some will take it, many will not. I have not run into the dragging part yet watching the Stanford course. Glad it is possible. Must linking gesture behaviors be coded?

Hm. But aren't there equally many things to understand for something like UIKit? To understand how events are captured by the framework and sent down the chain of responsibility for interaction handling you need to understand the Observer pattern for example. There's KVO, Selectors that are Swift-ugly and don't properly get verified at compile time. And you can very easily wind up with a situation where neither the code n'or IB reflect the actual view, because some is made in code and some is made in IB.

I honestly haven't used the "library" much for drag-n-drop SwiftUI views. But it's like "drag in a Button" and it will give you template code blocks that say Button(title) { onClick } or something like that. It still all happens in code, but you can drag and drop and use IB-like stuff and it will update the code for you. You can double-click the button in the view and edit the text, and the code will edit alongside it. You can add padding in the view and the code will get the corresponding padding added in and so on. As Apple themselves put it "It's the simplicity of Interface Builder, but with a single source of truth for your view".
I'm not really sure about gesture recognisers. Can have a look tomorrow.

Don't get me wrong. You obviously are good at coding. I just think it will toughen the experience for many.

Yeah; I mean, I get the feeling neither of us can really speak to the experience of a complete beginner?
In any case, I would never take offence to this. It's an interesting debate/discussion

No matter what I think both SwiftUI and UIKit have their advantages and I'd still say that if you could only learn one, make it UIKit. But learning both is better

 

[grandM]

It isn't only the starter. IMHO such fundamental changes result in burning people out. A good dev keeps up. There is plenty to learn AR,AI, ML... Apple introduced a new language and now changes another key part. No other industry does so. A few weeks ago some motivated IT'er confided in me. He said "I cannot keep studying and working. I worked my ass off. My relationship suffered and my wife blames me for not having children. I probably will seek a non IT job."

I know this guy. He is motivated. IT evolves but reinventing the wheel every 5 to 10 years makes no sense. Yes there will be benefits but they come at a price. People knew the quirks and became inexperienced again. New bugs will appear and people face a new learning curve to get a table view while they should be focussing on ARKit, etc

 

[casperes1996]

It isn't only the starter. IMHO such fundamental changes result in burning people out. A good dev keeps up. There is plenty to learn AR,AI, ML... Apple introduced a new language and now changes another key part. No other industry does so. A few weeks ago some motivated IT'er confided in me. He said "I cannot keep studying and working. I worked my ass off. My relationship suffered and my wife blames me for not having children. I probably will seek a non IT job."

I know this guy. He is motivated. IT evolves but reinventing the wheel every 5 to 10 years makes no sense. Yes there will be benefits but they come at a price. People knew the quirks and became inexperienced again. New bugs will appear and people face a new learning curve to get a table view while they should be focussing on ARKit, etc

I'm still in university so all my time is dedicated to learning, so take what I say with that in mind

Yes, there's a level of unnecessariness to a lot of it. But at the same time that unnecessariness is because a lot of it is fundamentally the same as has been done before with new names. If you learn the fundamentals it doesn't take that much extra to be caught up with the latest framework that does exactly the same thing as people were doing in the 70's just with new names, but at the same time, you still have to get familiar with the new names and conventions, so I totally get your IT pal, still. He's not wrong.

I do kinda think it's part of the allure of the field as well though. Obviously not when it's to the point where it hurts your work/life balance so much that your relationships become affected, but I think there's a nice middle ground to be hit, where we can still be an industry that often has shiny new toys to play with in our professional lives, rather than needing to do the exact same thing day our and day in, even if it is still in some way the same thing

 

[yellow8]

I'm currently sticking with UIKit, and will start SwiftUI with iOS 14. I have the feeling - based on what I read, might be wrong thus - that it's not entirely mature yet.
As mentioned before, I'll transition smoothly from UIKit to SwiftUI by starting with simple views, and then migrate progressively. When I'll feel comfortable enough, I might start a new app entirely with SwiftUI.

 

[throAU]

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

I'm just a hobby coder and watched the swiftUI presentation.

I'm going to convert over one of my toy apps but I think the above statement brings up a relevant point:

• if your UI can't be converted into swiftUI because it is too complex - then maybe your UI is simply too damn complex?

i.e., maybe its a signal to simplify your UI and/or split it off into different screens, so that it works across multiple devices better, irrespective of what kit you use to build it?

I'm not saying that's a 100% true thing 100% of the time. But it could be something to consider - is. your UI too complicated without good reason?

 

[grandM]

There was a survey amongst tech companies. Over 60 percent of employees suffer. There is a problem. The times I heard if you master one language etc. The industry would be better off if things as table views etc were not reinvented so people could learn new API as in functionality. IMHO someone now must know UIKit and SwiftUI if he wants to land a job basically having 2 ways to do the exact same thing. Other industries standardize and get work done. If needed a bit less efficient.

Employee burnout is a huge problem in the tech industry. This survey shows which companies have it the worst

A survey from anonymous message board app Blind reveals the 30 tech companies with the worst rates of employee burnout.

www.businessinsider.nl

 

[MisterSavage]

You say SwiftUI is easier to learn. It is not.

It is not "FOR YOU". You're entitled to your opinion but that was not the case at all for me.

 

[MisterSavage]

I'm currently sticking with UIKit, and will start SwiftUI with iOS 14. I have the feeling - based on what I read, might be wrong thus - that it's not entirely mature yet.

Without a doubt it's in the early stages. I keep hitting scenarios where I need things that were added for iOS 14 (fullScreenCover, toolbar, matchedGeometeryEffect, etc) that it would have been a pain to deal with not having.

 

[casperes1996]

There was a survey amongst tech companies. Over 60 percent of employees suffer. There is a problem. The times I heard if you master one language etc. The industry would be better off if things as table views etc were not reinvented so people could learn new API as in functionality. IMHO someone now must know UIKit and SwiftUI if he wants to land a job basically having 2 ways to do the exact same thing. Other industries standardize and get work done. If needed a bit less efficient.

Employee burnout is a huge problem in the tech industry. This survey shows which companies have it the worst

A survey from anonymous message board app Blind reveals the 30 tech companies with the worst rates of employee burnout.

www.businessinsider.nl

Do not propose a standardisation. I wouldn't want to have yet another new standard to deal with
But we dig our own graves. I'm sure if you asked, programmers would also, almost unanimously, say yes to "Do you sometimes sit and think 'Oh I'd love to try that new framework', or dream about creating your own new language or framework?'".

Without a doubt it's in the early stages. I keep hitting scenarios where I need things that were added for iOS 14 (fullScreenCover, toolbar, matchedGeometeryEffect, etc) that it would have been a pain to deal with not having.

Honestly, the biggest improvement IMO isn't even new features... Just the fact that the error messages are now actually meaningful just makes all the difference.

 

[slooksterPSV]

Anyone did the full switch from Swift to SwiftUI ?

I personally find the learning of SwiftUI kind of hard....

I thought I would chime in here. Coming from a WinForms, WPF, UWP, Qt, etc. background, SwiftUI seems very simple to grasp and understand. One of the confusing things, I think, for most people, will probably be the chaining of functions to setup the UI element. I've seen UIKit and its what I would expect to see with all other frameworks. SwiftUI seems very... I don't know how to put this other than a mixture of LINQ (C# sugar) and CSS.

To have full access to a control is useful, and I'm trying to figure out if you're limited in SwiftUI for what you can/can't do with a UI control where I feel like UIKit you wouldn't be. Programmatically, while I would assume you can change things on the fly for UI elements with SwiftUI - it doesn't seem simply apparent (with where I'm at in my reading). However, UIKit I could see it be feasible if the properties were declared as a struct/class object.

While I'm learning SwiftUI, I know for sure I'll need to learn UIKit - even with sticking mainly with Swift instead of Objective-C.

 

[casperes1996]

To have full access to a control is useful, and I'm trying to figure out if you're limited in SwiftUI for what you can/can't do with a UI control where I feel like UIKit you wouldn't be. Programmatically, while I would assume you can change things on the fly for UI elements with SwiftUI - it doesn't seem simply apparent (with where I'm at in my reading). However, UIKit I could see it be feasible if the properties were declared as a struct/class object.

SwiftUI is definitely more limited at this time. Apple however, with every release makes it less limited, but it still will probably remain more limited than UIKit forever in some capacity. I see it kinda like an abstraction level above UIKit, similar to how UIKit sort of is an abstraction level about CoreAnimation and CoreGraphic directly drawing on the screen. smaller jump up, but still sort of a jump up in a way. But I think 99% of views will be definable in SwiftUI with neater and less code than a traditional procedural approach. And unlike Storyboards with UIKit having a single source of truth where the code always reflects the view 100% is IMO very nice.

While I'm learning SwiftUI, I know for sure I'll need to learn UIKit - even with sticking mainly with Swift instead of Objective-C.

Yeah I definitely recommend learning both as well. And if you already have experience with other frameworks I think you'll have a fairly easy time as well anyway. Though I say that with 0 knowledge of writing UWP or WinForms. It's not so different to the Android SDK or some of the Java stuff I've worked with at least - least not in basic principle, though I prefer UIKit to those

 

[throAU]

The big thing with swiftUI as I see it is that it is adaptable to different displays without the coder having to do much (at least, not much extra work) at all.

Not just for cross platform between Mac and iOS, but also watchOS, etc.

I haven't played with it yet, and initially got spooked by it being the default in clean installs of Xcode when I got my new Mac, but since watching the developer presentation I'm keen to give it a go.

I don't see it replacing UIkit for everything just yet; as above it can't do everything UIkit can do. But for the purposes of making an app that runs on multiple platforms of differing UIs - it looks like THAT will be a lot more straightforward.

And again. Maybe it doesn't NEED to do everything UIkit can do. UIkit has decades of baggage with it. Does your app really need a UI that complex that you *need* to do things only UIkit can do? Can you re-think it to be simpler and more adaptable?

I see migration for legacy apps being a bit of a pain. But for new apps, swiftUI first makes sense.

 

[robbieduncan]

To have full access to a control is useful, and I'm trying to figure out if you're limited in SwiftUI for what you can/can't do with a UI control where I feel like UIKit you wouldn't be. Programmatically, while I would assume you can change things on the fly for UI elements with SwiftUI - it doesn't seem simply apparent (with where I'm at in my reading).

Swift UI requires a different way of thinking. If you previously had a function that your UI called to swap to elements via visibility (pseudo-code):

swapElements(){
 element1.visible = false
 element2.visible = true
}

In swift UI you would do something like

struct myView : View {
@State private var element1Visible = true

function swapElements() {
element1Visible = false
}

var body : some View {
 if element1Visible {
  Text("Element 1")
 } else {
  Text("Element 2")
 }
 Button(action:swapElements) {
  Text("Swap")
 }
} 
}

So in Swift UI we declare all the UI (all possible ways it can look) and control them via state variables (or variables in the environment or observed objects). SwiftUI will automatically redraw/recreate the view when the state changes

 

[slooksterPSV]

And again. Maybe it doesn't NEED to do everything UIkit can do. UIkit has decades of baggage with it. Does your app really need a UI that complex that you *need* to do things only UIkit can do? Can you re-think it to be simpler and more adaptable?

100 times this. I feel like for iOS, complex UIs shouldn't be there. iPad OS - you have more screen space so I can see more complex interfaces, but why? Show more information/data and make it look clean. The most complex app I've seen on iOS for views would be the C# programming application. You have 3 views - code, file browsing-like, and runtime view. But most apps don't really need this level of complexity. Word, Excel, Pages, Numbers, etc. keep things clean.

 

[MisterSavage]

And again. Maybe it doesn't NEED to do everything UIkit can do. UIkit has decades of baggage with it. Does your app really need a UI that complex that you *need* to do things only UIkit can do? Can you re-think it to be simpler and more adaptable?

In similar thinking from what I understand that's why SwiftUI uses structs instead of classes for its Views. They don't inherit tons of functionality from higher classes that you might never use.

 

[casperes1996]

100 times this. I feel like for iOS, complex UIs shouldn't be there. iPad OS - you have more screen space so I can see more complex interfaces, but why? Show more information/data and make it look clean. The most complex app I've seen on iOS for views would be the C# programming application. You have 3 views - code, file browsing-like, and runtime view. But most apps don't really need this level of complexity. Word, Excel, Pages, Numbers, etc. keep things clean.

"complexity" can also just be out of the ordinary but still clean and simple, but with a unique identity.
However; What C# programming app? Considering apps being able to run arbitrary code is a breach of the App Store guidelines... I need to get that before it disappears.

 

[robbieduncan]

In similar thinking from what I understand that's why SwiftUI uses structs instead of classes for its Views. They don't inherit tons of functionality from higher classes that you might never use.

SwiftUI structs describe the view you would like to be created. They do not specify instances of views or exactly how the SwiftUI system should create the view you described. On different platforms the same SwiftUI struct will result in a different class/view hierarchy.

 

[throAU]

but with a unique identity.

See, this is something that goes against the UI design principles of the native platform; I'm assuming you're talking about "unique identity" in terms of visual layout here.

So whilst some developers may want to do this, it's probably a bad idea, if you want it to feel like a native application, and behave like a native application and be easy to use.

 

[casperes1996]

See, this is something that goes against the UI design principles of the native platform; I'm assuming you're talking about "unique identity" in terms of visual layout here.

So whilst some developers may want to do this, it's probably a bad idea, if you want it to feel like a native application, and behave like a native application and be easy to use.

I agree with that most of the time, but not always. It's true like 99% of the time and it would take a greater budget to give an app a unique identity while still feeling like it fits into the system UI, but Apple has even given design awards to apps that do this in the past. I would say something like Vectornator also has a very unique style visually, though I'm not sure if they achieved it with very standard view components.

 

[throAU]

I agree with that most of the time, but not always. It's true like 99% of the time and it would take a greater budget to give an app a unique identity while still feeling like it fits into the system UI, but Apple has even given design awards to apps that do this in the past. I would say something like Vectornator also has a very unique style visually, though I'm not sure if they achieved it with very standard view components.

I'd agree with that. But yeah, 99% of the time means that you only need to dive into UIKit 1% of the time, and you better have a good reason for it.

 

[slooksterPSV]

"complexity" can also just be out of the ordinary but still clean and simple, but with a unique identity.
However; What C# programming app? Considering apps being able to run arbitrary code is a breach of the App Store guidelines... I need to get that before it disappears.

‎Continuous .NET C# and F# IDE

‎Continuous is a fast and powerful .NET C# and F# IDE that runs directly on the iPad and iPhone (no network needed!). With it, you can write apps and games using your favorite languages on your favorite devices. Continuous is always building and running your code so you can see changes as you...

apps.apple.com

Continuous. Its awesome =). There's many where you can run arbitrary code.... this one is $9.99 but I've seen others on there.

 

[casperes1996]

‎Continuous .NET C# and F# IDE

‎Continuous is a fast and powerful .NET C# and F# IDE that runs directly on the iPad and iPhone (no network needed!). With it, you can write apps and games using your favorite languages on your favorite devices. Continuous is always building and running your code so you can see changes as you...

apps.apple.com

Continuous. Its awesome =). There's many where you can run arbitrary code.... this one is $9.99 but I've seen others on there.

Thanks!
Weird though. App Store rules clearly state (or at least did last I checked) that the only kind of arbitrary code execution allowed is webkit views running JS