https://kotlinlang.org logo
Join Slack
Powered by
I've spent sometime looking at the different decla...
# compose
k
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.
t
compose feels a bit lower level than SwiftUI to me right now, not in a bad way. Maybe it will change going forward.
k
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.
So I get culturally why SwiftUI examples tend to have more application logic embedded into it, I just don't agree with it lol.
t
yeah it's rough, I think it's part of the reason theres such an obsession with architecture in that community.
k
Theres an obsessions with architecture in the iOS dev community? That hasn't been the case in my experience.
t
it's a topic of a lot of debate there
k
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.
Oh ya its certainly a debate
but the debate is always on whether common code design techniques are valuable
t
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)
k
I like UIKit, but having something more modern will be nice
I wish Apple didn't release SwiftUI as a released product tho
Its extremely buggy and lacks many features
t
I also wish they didn't do the "big reveal" every year and where more transparent and iterative like the android and jetbrains team
that'l likely never happen though
k
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.
Ya the "big reveal" on developer stuff hurts everyone
Its not like I can pop into a Slack channel and @ some Apple engineer with an issue about SwiftUI a/ws
I wish I could lol
Seriously as an iOS developer them pushing for having so much Application logic in the views hurts code readability so much
c
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
k
Yikes
I can't believe they released that library as considered stable
t
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.
but I agree that apple doesn't currently make this obvious and kind of encourages mixing presentation logic with app logic
I've been applying elm / redux architecture for smaller apps on iOS and the web and I find that works really well for producing thin views
k
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.
t
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
j
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.
t
Yeah I'm using it in 2 apps in the store, they're partly UIKit as well though
👍🏻 1
biggest problem I have with it right now is navigation
j
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.
k
What % of your crashes are from SwiftUI?
c
@krtko have you looked at the Point•Free stuff? they do an FP and Redux-style idiom with SwiftUI..
k
No
My main issue is just crashes lol
c
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)….
t
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.
👍🏻 1
k
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!
c
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?
k
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.
👍🏻 1
The Android and iOS communities seem very different to me. Apple's dev community takes anything Apple says as the gold standard. So if they spent time going over common and accepted coding practices I think it would benefit its community a ton.
t
Nope no crashes from SwiftUI, quite a few from compose though but thats far earlier along 😅
k
Wow no crashes reported at all? lol Are you using Compose in production?
c
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?
I totally agree about pre-AS android, before KitKat, my interest level in working in it was subzero…
I have written a lot of code on ios in O-C, Modern O-C, and a lot in Swift, and sure some controllers got out of control, but that’s nothing, my main complaints about ios are all the time that went up the flue on autolayout, then adaptive design, and the size classes, and storyboards, ultimately only to admit it was a boat to nowhere….
k
Oh but tech always evolves and changes. Your past knowledge helps you learn whats new.
lol size classes were always a disaster IMO
I kinda expect they'll reinvent auto-layout for SwiftUI
c
a declarative AL might be kind of interesting, I am skeptical about the declarative ConstraintLayout, but time will tell…
k
They are testing that out in Compose. It looks pretty clunky TBH but I imagine they'll work that out
Oh thats what you were referring to with the 
declarative ConstraintLayout
i'm guessing
👍🏻 1
I like constraint based layouts, but they come at a performance cost
they also tend to not adapt as well to different screen sizes
c
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…
k
Are you an IB user or do you layout your views in code?
c
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
t
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 🙂
k
I'm also sure SwiftUI's and Composes api surface is going to change quite a bit over the next few years
@codeslubber I hate the IB, I've successfully convinced everywhere I've worked to migrate to SnapKit/Masonry. I'm glad SwiftUI is finally going to fix so much of whats wrong with IB.
c
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…
I looked at SnapKit, kind of nice…
k
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.
I've read through some nightmare layouts before, because they had view creation in three different places, constraints randomly being set helter skelter
I know u could say that about "most code" but nothing is harder to read IMO than poorly organized programmatic layouts lol
c
dude you can make a mess with anything, having seen a mess does not mean a feature or framework is bad
my problem with IB is it’s easy to get one thing up and looking good quick
time to get all views, in different sizes, devices, zipped up and pretty? a ton
not to mention there’s finish work, which sucks, cause ripping things up after finishing them is infuriating….
k
Lol i know u can make a mess of anything, but programmatic views suffer from that most the most IMO
That wasn't a statement about any particular programmatic layout system
Ya IB always feels like something that was made to handle a single screen size using only Apple provided views and styles
c
which it was more or less at first
and when the ipad first came out
you had to remake EVERY screen!
later with adaptive, instead, you could just write 4 or 500 constraints to keep it to ‘one’ … lmao
k
Ya Apple thinking they could contain all the different screen sizes and orientations into four size classes was such a mistake
6 Views
Open in Slack
PreviousNext
Powered by