4 ms·

Haven't done Swift and Cocoa in a while, but is there any major disadvantage to just not using SwiftUI?

by sgt 4y ago

AJRF 4y ago
Apple keep pushing it incredibly hard, despite it being poorly implemented. The net effect is less thoughtful developers use it because Apple push it. Eventually it will infect your project because those developers will start pushing it into new features. I regret not being more vocal in my current job about not using it in production and now we have a huge amount of bugs caused by it even between point releases of iOS.
- data-ottawa 4y ago
  It’s certainly a lower barrier of entry, which is both good and bad. I can mock up an app on my iPad or build some simple utilities quickly, but one things get complex it can become difficult to debug.
alin23 4y ago
Author here! Aside from Lunar (https://lunar.fyi/ https://lunar.fyi/) all my apps over at https://lowtechguys.com/ https://lowtechguys.com/ are 100% SwiftUI. In my extensive experience, this is the only major disadvantage I found: UIs with hundreds of stylized elements can be too slow I suspect this happens especially because adding style to an element makes the graph deeper (e.g. Text(“”).shadow().colorInvert() means SwiftUI will add three function calls in the stack on each render pass) But if that case does not apply to your UI, the advantages are massive. For example my Volum [1] app works on iOS, iPadOS and macOS and because of SwiftUI it shares 95% of the code between platforms. That’s hard enough with other frameworks that I couldn’t even consider starting such a project before SwiftUI. [1] https://lowtechguys.com/volum https://lowtechguys.com/volum
- soapdog 4y ago
  Your apps look really neat. :D
  - alin23 4y ago
    Thanks! ^_^
- xiaolingxiao 4y ago
  hey i also build mobile apps in swiftui. do you have more resources on why $binding could be slow?
  - alin23 4y ago
    Well, it's not @Binding that's slow, it's the fact that it's not immutable like @State, so on each `body` call, the binding's `get()` function has to be called again.
volleygman180 4y ago
It's been out for 3 years, but it's honestly still quite rough around the edges. It's like the highways and some roads are paved, but otherwise you're off-roading if you need to drive outside of the city. There's a fair bit of UIKit-parity that's still missing, which forces you to create a ViewRepresentable class and do the UIKit bridging yourself (this ranges in complexity, but can definitely present significant challenge depending on the task). This becomes more frequent too for lesser used Apple platforms (watchOS and tvOS). Another place that's lacking that the author doesn't quite dig into is that SwiftUI has no concept of cell re-use at all. The Lazy UI components (stacks, grids) will _delay_ their initialization, however, nothing actually ever gets re-used. So if you're working with a layout similar to Netflix, every time you scroll left/right/up/down, new cells are being created and are loading more image data into memory. With UIKit, cell re-use is a foundational concept that all devs should be utilizing, so it's a bit of a headscratcher that something like this is still missing from SwiftUI by now. To top it all off, as Apple does get SwiftUI up to spec, they are completely resistant to releasing support libraries (or anything along those lines) - so rudimentary UI features/modifiers/etc. that get added years later will only ever support the latest version of iOS and forward. This makes it much more restrictive to work with, as most apps are targeting at least 1 year back and not only the latest major version of the OS.
- ericmay 4y ago
  > The Lazy UI components (stacks, grids) will _delay_ their initialization, however, nothing actually ever gets re-used. So if you're working with a layout similar to Netflix, every time you scroll left/right/up/down, new cells are being created and are loading more image data into memory. What's the trade-off here for loading versus pre-loading? I guess if you are pre-loading all of that content is loaded into memory from the start, right? I'm guessing there's a performance advantage to have images pre-loaded, but then: 1. Are you doing that dynamically? How would you know what content to pre-load onto the device? My Netflix queue is different from others. 2. If you're loading a lot of content (like scrolling left/right to get new titles) maybe it makes sense to guess/decide what the next cells off the screen might be and load those up as the user scrolls versus loading them for sure, and what about the case where the user scrolls down/up but not left right? You wouldn't necessarily want to load all of that content unless you know the user is going to look at it? Also wondering how for Netfilx this would factor into their algorithms. If I "like" a show when I first load the app if they pre-load the cells then they'll have more compute to re-load all the cells to change their recommendations? Curious about this.
meindnoch 4y ago
Apple is trying very hard to shove it down the developers’ throats. E.g. they make certain new OS frameworks SwiftUI-only, like the new “dynamic island” APIs for iPhone 14. (Pretty misguided in my opinion, but it’s their platform to ruin…)
- stephc_int13 4y ago
  I am almost convinced that they will follow this path and I've made my mind about abandoning development for Apple platforms a while ago. Objective-C is an awful mess but at least the toolchain is able to natively mix Objective-C, C and C++ code without much effort. And the low-level parts of iOS are still using C API. Google tried the same thing at first, Java was the only supported API for many years, they reluctantly added the NDK for "special uses".
  - meindnoch 4y ago
    Yes, it is quite saddening. iOS used to be the platform that destroyed Android in user experience in no small part due to its “bare metal” programming model. I still remember how laughably slow and laggy my friends’ Android devices were, with their top of the line Snapdragon whatever uber CPU, compared to my meager iPhone 4. If I wanted a device with 100ms input latency, passing all of my gestures through countless layers of indirections and declarative tree-diffing nonsense, I may as well use an Android that doesn’t require me to shell out $150 annually to install my own software…

Haven't done Swift and Cocoa in a while, but is there any major disadvantage to just not using SwiftUI?

by sgt 4y ago

Haven't done Swift and Cocoa in a while, but is there any major disadvantage to just not using SwiftUI?

AJRF 4y ago

Apple keep pushing it incredibly hard, despite it being poorly implemented. The net effect is less thoughtful developers use it because Apple push it. Eventually it will infect your project because those developers will start pushing it into new features. I regret not being more vocal in my current job about not using it in production and now we have a huge amount of bugs caused by it even between point releases of iOS.

data-ottawa 4y ago
It’s certainly a lower barrier of entry, which is both good and bad. I can mock up an app on my iPad or build some simple utilities quickly, but one things get complex it can become difficult to debug.

alin23 4y ago

Author here! Aside from Lunar (https://lunar.fyi/ https://lunar.fyi/) all my apps over at https://lowtechguys.com/ https://lowtechguys.com/ are 100% SwiftUI. In my extensive experience, this is the only major disadvantage I found: UIs with hundreds of stylized elements can be too slow I suspect this happens especially because adding style to an element makes the graph deeper (e.g. Text(“”).shadow().colorInvert() means SwiftUI will add three function calls in the stack on each render pass) But if that case does not apply to your UI, the advantages are massive. For example my Volum [1] app works on iOS, iPadOS and macOS and because of SwiftUI it shares 95% of the code between platforms. That’s hard enough with other frameworks that I couldn’t even consider starting such a project before SwiftUI. [1] https://lowtechguys.com/volum https://lowtechguys.com/volum

soapdog 4y ago
Your apps look really neat. :D
- alin23 4y ago
  Thanks! ^_^
xiaolingxiao 4y ago
hey i also build mobile apps in swiftui. do you have more resources on why $binding could be slow?
- alin23 4y ago
  Well, it's not @Binding that's slow, it's the fact that it's not immutable like @State, so on each `body` call, the binding's `get()` function has to be called again.

volleygman180 4y ago

It's been out for 3 years, but it's honestly still quite rough around the edges. It's like the highways and some roads are paved, but otherwise you're off-roading if you need to drive outside of the city. There's a fair bit of UIKit-parity that's still missing, which forces you to create a ViewRepresentable class and do the UIKit bridging yourself (this ranges in complexity, but can definitely present significant challenge depending on the task). This becomes more frequent too for lesser used Apple platforms (watchOS and tvOS). Another place that's lacking that the author doesn't quite dig into is that SwiftUI has no concept of cell re-use at all. The Lazy UI components (stacks, grids) will _delay_ their initialization, however, nothing actually ever gets re-used. So if you're working with a layout similar to Netflix, every time you scroll left/right/up/down, new cells are being created and are loading more image data into memory. With UIKit, cell re-use is a foundational concept that all devs should be utilizing, so it's a bit of a headscratcher that something like this is still missing from SwiftUI by now. To top it all off, as Apple does get SwiftUI up to spec, they are completely resistant to releasing support libraries (or anything along those lines) - so rudimentary UI features/modifiers/etc. that get added years later will only ever support the latest version of iOS and forward. This makes it much more restrictive to work with, as most apps are targeting at least 1 year back and not only the latest major version of the OS.

ericmay 4y ago
> The Lazy UI components (stacks, grids) will _delay_ their initialization, however, nothing actually ever gets re-used. So if you're working with a layout similar to Netflix, every time you scroll left/right/up/down, new cells are being created and are loading more image data into memory. What's the trade-off here for loading versus pre-loading? I guess if you are pre-loading all of that content is loaded into memory from the start, right? I'm guessing there's a performance advantage to have images pre-loaded, but then: 1. Are you doing that dynamically? How would you know what content to pre-load onto the device? My Netflix queue is different from others. 2. If you're loading a lot of content (like scrolling left/right to get new titles) maybe it makes sense to guess/decide what the next cells off the screen might be and load those up as the user scrolls versus loading them for sure, and what about the case where the user scrolls down/up but not left right? You wouldn't necessarily want to load all of that content unless you know the user is going to look at it? Also wondering how for Netfilx this would factor into their algorithms. If I "like" a show when I first load the app if they pre-load the cells then they'll have more compute to re-load all the cells to change their recommendations? Curious about this.

meindnoch 4y ago

Apple is trying very hard to shove it down the developers’ throats. E.g. they make certain new OS frameworks SwiftUI-only, like the new “dynamic island” APIs for iPhone 14. (Pretty misguided in my opinion, but it’s their platform to ruin…)

stephc_int13 4y ago
I am almost convinced that they will follow this path and I've made my mind about abandoning development for Apple platforms a while ago. Objective-C is an awful mess but at least the toolchain is able to natively mix Objective-C, C and C++ code without much effort. And the low-level parts of iOS are still using C API. Google tried the same thing at first, Java was the only supported API for many years, they reluctantly added the NDK for "special uses".
- meindnoch 4y ago
  Yes, it is quite saddening. iOS used to be the platform that destroyed Android in user experience in no small part due to its “bare metal” programming model. I still remember how laughably slow and laggy my friends’ Android devices were, with their top of the line Snapdragon whatever uber CPU, compared to my meager iPhone 4. If I wanted a device with 100ms input latency, passing all of my gestures through countless layers of indirections and declarative tree-diffing nonsense, I may as well use an Android that doesn’t require me to shell out $150 annually to install my own software…