I've spent sometime looking at the different declarative UI frameworks (Compose, SwiftUI, and Flutter) coming out and I really appreciate Compose's dedication to not embedding application logic in the view.

compose feels a bit lower level than SwiftUI to me right now, not in a bad way. Maybe it will change going forward.

Its very common to mix application logic heavily into your view on iOS. Theres a different culture of developers in the iOS space from my experience. Large spaghetti code view + viewcontrollers are somewhat of the suggest code design by Apple themselves.

yeah it's rough, I think it's part of the reason theres such an obsession with architecture in that community.

Theres an obsessions with architecture in the iOS dev community? That hasn't been the case in my experience.

it's a topic of a lot of debate there

Theres almost no concept of dependency management in iOS. Almost everything is statically references. Most if not all application logic resides in the ViewController which also handles manipulating the view.

I'm pretty happy to see the back of UIKit to be honest and hopefully wwdc really polishes SwiftUI since I quite like it (Compose too)

I like UIKit, but having something more modern will be nice

I also wish they didn't do the "big reveal" every year and where more transparent and iterative like the android and jetbrains team

Honestly its kinda surprising that they released it in the state it is in. Even if iOS 14 has a "perfect" SwiftUI, because its going to be 2-3 years before iOS 14 is the min SDK we target, its going to be a while before most ppl can use it.

and there’s zero testing in the SwiftUI world that I can find, they did that tutorial, which was the first sample worth a damn from apple in at least 5 years, but no tests, no plans for tests, no words nothing

Yikes

you can architect SwiftUI apps in a way that you don't need to put any logic in views, for that reason I haven't needed to unit test SwiftUI views themselves.

Ya it's the same case with UIKit and their view controller system. You don't have to throw a ton of layout logic into the view controller, but that's the code design Apple pushes and thus it's the most common one.

yeah I wonder what some of the apple internal codebases look like if thats what they encourage third party developers to do 🤔 then again they historically don't care that much about third party developers

SwiftUI and tooling is pretty usable now for real (small to medium sized) Apps. But I think that only became case in last Xcode release. Still various limitations and bugs, but the advantages are starting outweigh costs. You will have to do some hacks/workarounds. However, your app will be way easier to update/modify in the future.

Yeah I'm using it in 2 apps in the store, they're partly UIKit as well though

That was completely broken until the .4(?) releases. Really basic stuff wouldn’t work properly, especially in simulator. I’ve actually been mainly doing MacOS stuff so it is less of an issue.

What % of your crashes are from SwiftUI?

@krtko have you looked at the Point•Free stuff? they do an FP and Redux-style idiom with SwiftUI..

No

ok well your treatise about SwiftUI not solving the massive controller problem prompted my suggestion, there are no massive controllers in their stuff, and they do tests too (unlike the Swift Talk guys)….

I haven't had any crashes with it, there are bugs for sure but nothing that stopped me shipping stuff. Just a lot of stuff missing that you need to use UIKit for right now.

You don't have any crashes reported from it? I had it crash on me in just a simple demo app of it. I'd love to use it just for the view previewing feature. @codeslubber You can total structure SwiftUI code in a well designed manor. I just wish Apple would focus on it more. They have a chance to fix the VC spaghetti hell that is iOS development!

I agree that Apple has not been as bold, they have taken no real position. But if you look at Android, you could argue Apple was smart. I loved the Android Architecture patterns but the community spat on them, because they were afraid they might make Dagger and Rx and other pets seem less important. So Android coddled all the parties now I don’t even know if Android is encouraging me to use their classes anymore, pretty sure they are not. And they just rolled out a Dagger wrapper (Hilt). Its like high school. When will we just have an approach that works, that’s clear, is documented? and has non-trivial samples and tutorials?

Haha did you ever do Android development before Android Studio was a thing? Back then Android was a complete shit show. It has come a surprisingly long way.

Nope no crashes from SwiftUI, quite a few from compose though but thats far earlier along 😅

Wow no crashes reported at all? lol Are you using Compose in production?

You act like they do that out of slavish devotion, and sure there is some of that, but having a designated way to do things, that is documented, with sample code, used to be de rigeur. Now, everybody has their own snowflake bro stack (no 2 are the same) and you can’t even find any samples that aren’t laughably simplistic… that’s better?

Oh but tech always evolves and changes. Your past knowledge helps you learn whats new.

a declarative AL might be kind of interesting, I am skeptical about the declarative ConstraintLayout, but time will tell…

They are testing that out in Compose. It looks pretty clunky TBH but I imagine they'll work that out

yeah constraints are awesome, especially for animations, and for transforming views to accommodate minor modal differences, e.g. you said no to one thing, so I can slide some part of a form away…

Are you an IB user or do you layout your views in code?

I was using IB for most projects. The group of old schoolers who stuck to O-C and thought their code was much cleaner were a pretty silly lot I thought, but.. it’s funny, I kinda thought they might get there with IB and SBs and AL. But then when Adaptive dropped and you could change the constraints in the UI and it would scramble the XML, I thought ‘all is lost’… lol

I'm not using compose in prod no, just playing around with it trying to rebuild an iOS app I have in it, so far I like it just heaps of stuff breaks, but thats the price of early adoption 🙂

I'm also sure SwiftUI's and Composes api surface is going to change quite a bit over the next few years

my problem with that is the same one I noted above: you depart for a land where you have a snowflake world and you are also now at the mercy of n + 1 upstream providers…

At the mercy of the SnapKit team? Its API has been very stable. Ultimately ur at the mercy of Apple who tends to breaks backward compatibility all the time a/ws. I don't really see this as an issue. One of the tricks of doing UI layouts in code, is to stay super principled with how you layout the code. Its annoying at first, but it pays back in dividends when u need to edit something.

dude you can make a mess with anything, having seen a mess does not mean a feature or framework is bad

Lol i know u can make a mess of anything, but programmatic views suffer from that most the most IMO

which it was more or less at first

Ya Apple thinking they could contain all the different screen sizes and orientations into four size classes was such a mistake