6 ms·

Using Apple's Combine Framework

jamil7 7y ago
Can combine in it's current state completely replace RxSwift in a project? (disregarding compatability).
- langitbiru 7y ago
  That's my question as well. Should I learn both technologies for greenfield projects or just use Combine?
  - hamdshah 7y ago
    Combine is only iOS-13 If you wanna support any OS before that you have to use RxSwift for that
- hamdshah 7y ago
  I believe it does replace RxSwift other then some operators that the Combine doesn't have currently can be easily added.
mrtksn 7y ago
Not long ago I got tired of some web technologies and decided to look into iOS native app building. It took me some time to un-learn many things and have that "aha moment" but when I got it, I'm no longer craving for JS - except for few things that I think are better on the JS world and that is the when UI building is done better with code. In my experience when you have a situation where you want to represent data visually, it's more intuitive to create the UI by code and I find that UIKit is not much fun when dealt with only through code and no WYSIWYG interface building tools(btw WYSIWYG on XCode is not like Dreamviewer, it actually works pretty well and helps you more than limits you). This SwiftUI + Combine thing seems to fix that pretty well. It's unfortunate that it's iOS13+ only. One thing that I kept craving when I switched to native app development was ReduxJS like state management and visual UI for data management so I build one for myself[0]. Right now there are few friction points of keeping the UI in sync with the state but I think there's now a real opportunity with Combine to have nice state management like with ReduxJS in iOS. [0] SwiftyState is an open source state management library inspired by ReduxJS and built with Swift 5: https://github.com/mrtksn/SwiftyState https://github.com/mrtksn/SwiftyState
- melling 7y ago
  Apple is very good about getting iPhone users upgraded. https://gs.statcounter.com/ios-version-market-share/mobile-tablet/worldwide https://gs.statcounter.com/ios-version-market-share/mobile-t... If you’re new to iOS or don’t support a large audience, within 6 months most people will be using iOS 13.
  - mrtksn 7y ago
    True but the maturity of the framework is also questionable, they changed quite a few things since the introduction. I think we should wait a bit before going all in :)
  - skohan 7y ago
    For professional projects I have worked on, the rule of thumb we have landed on is usually to support 2 versions older than the current version. Yes it's usually a small minority of users who haven't upgraded, but that tends to be people with older phones who can't update to the latest version. It makes my life harder, but it's better than punishing users who can't afford to upgrade their phone often.
- jmkni 7y ago
  I've done a little bit of Native iOS, the main thing I found annoying was having to build UI's using a drag/drop editor. On web you have HTML, on Android you can ignore the UI builder and write XML, on WPF/Xamarin Forms you have XAML, but on iOS you have to either use the drag/drop editor or build your UI in Swift/Objective C. Both feel messy. You can edit the XML generated manually of course, but it's clearly not supported, and isn't as intuitive as other UI frameworks (as far as I can tell). Maybe I just need to spend more time with iOS, I only spent a couple of months working on that app, and didn't do a lot of UI work but that was my initial takeaway.
  - pjmlp 7y ago
    I on the other hand miss Delphi for Web, but thanks to WebAssembly that might be a thing.
skohan 7y ago
I fear that battle is already lost on this one, but I'm disappointed to see FRP making it into the officially supported workflow on mobile. I think FRP has a place, and React has been a transformative technology for web, but in that case you generally don't even have to think about the rx primitives at all if you don't want to. As far as RX as it's penetrated mobile development in the past few years, the result I have seen is that many projects have become unreadable tangles of reactive chains, where the stack trace is no longer useful, because of the unfounded assumption that "more reactive" means better code. The iOS APIs are certainly showing their age, and there's a lot of warts related to their Objective-C pedigree, but I think they have always had a strength in terms of being fairly agnostic about how they are integrated into your program's structure. I really fear that sense will be lost if third party libraries adopt combine as the dominant interface paradigm.
- ajconway 7y ago
  More reactive usually means less global state, which is generally for the better. It also encourages functional purity where possible. Previously (briefly) in iOS/macOS there was an attempt to move to closure-based APIs, which led to unreadable tangles of function invocations with often surprising calling threads. Before that for a long time there was a weak delegate object pattern, probably the least convenient way of interacting with things.
  - pjmlp 7y ago
    It also means more memory being used.
    - ajconway 7y ago
      Do you mean that it tends to require using immutable data structures?
      - pjmlp 7y ago
        Yes, and that it gets generated and thrown away in each view update, even if a view diff is taken into account.

Can combine in it's current state completely replace RxSwift in a project? (disregarding compatability).

langitbiru 7y ago
That's my question as well. Should I learn both technologies for greenfield projects or just use Combine?
- hamdshah 7y ago
  Combine is only iOS-13 If you wanna support any OS before that you have to use RxSwift for that
hamdshah 7y ago
I believe it does replace RxSwift other then some operators that the Combine doesn't have currently can be easily added.

Not long ago I got tired of some web technologies and decided to look into iOS native app building. It took me some time to un-learn many things and have that "aha moment" but when I got it, I'm no longer craving for JS - except for few things that I think are better on the JS world and that is the when UI building is done better with code. In my experience when you have a situation where you want to represent data visually, it's more intuitive to create the UI by code and I find that UIKit is not much fun when dealt with only through code and no WYSIWYG interface building tools(btw WYSIWYG on XCode is not like Dreamviewer, it actually works pretty well and helps you more than limits you). This SwiftUI + Combine thing seems to fix that pretty well. It's unfortunate that it's iOS13+ only. One thing that I kept craving when I switched to native app development was ReduxJS like state management and visual UI for data management so I build one for myself[0]. Right now there are few friction points of keeping the UI in sync with the state but I think there's now a real opportunity with Combine to have nice state management like with ReduxJS in iOS. [0] SwiftyState is an open source state management library inspired by ReduxJS and built with Swift 5: https://github.com/mrtksn/SwiftyState https://github.com/mrtksn/SwiftyState

melling 7y ago
Apple is very good about getting iPhone users upgraded. https://gs.statcounter.com/ios-version-market-share/mobile-tablet/worldwide https://gs.statcounter.com/ios-version-market-share/mobile-t... If you’re new to iOS or don’t support a large audience, within 6 months most people will be using iOS 13.
- mrtksn 7y ago
  True but the maturity of the framework is also questionable, they changed quite a few things since the introduction. I think we should wait a bit before going all in :)
- skohan 7y ago
  For professional projects I have worked on, the rule of thumb we have landed on is usually to support 2 versions older than the current version. Yes it's usually a small minority of users who haven't upgraded, but that tends to be people with older phones who can't update to the latest version. It makes my life harder, but it's better than punishing users who can't afford to upgrade their phone often.
jmkni 7y ago
I've done a little bit of Native iOS, the main thing I found annoying was having to build UI's using a drag/drop editor. On web you have HTML, on Android you can ignore the UI builder and write XML, on WPF/Xamarin Forms you have XAML, but on iOS you have to either use the drag/drop editor or build your UI in Swift/Objective C. Both feel messy. You can edit the XML generated manually of course, but it's clearly not supported, and isn't as intuitive as other UI frameworks (as far as I can tell). Maybe I just need to spend more time with iOS, I only spent a couple of months working on that app, and didn't do a lot of UI work but that was my initial takeaway.
- pjmlp 7y ago
  I on the other hand miss Delphi for Web, but thanks to WebAssembly that might be a thing.

skohan 7y ago

I fear that battle is already lost on this one, but I'm disappointed to see FRP making it into the officially supported workflow on mobile. I think FRP has a place, and React has been a transformative technology for web, but in that case you generally don't even have to think about the rx primitives at all if you don't want to. As far as RX as it's penetrated mobile development in the past few years, the result I have seen is that many projects have become unreadable tangles of reactive chains, where the stack trace is no longer useful, because of the unfounded assumption that "more reactive" means better code. The iOS APIs are certainly showing their age, and there's a lot of warts related to their Objective-C pedigree, but I think they have always had a strength in terms of being fairly agnostic about how they are integrated into your program's structure. I really fear that sense will be lost if third party libraries adopt combine as the dominant interface paradigm.

ajconway 7y ago
More reactive usually means less global state, which is generally for the better. It also encourages functional purity where possible. Previously (briefly) in iOS/macOS there was an attempt to move to closure-based APIs, which led to unreadable tangles of function invocations with often surprising calling threads. Before that for a long time there was a weak delegate object pattern, probably the least convenient way of interacting with things.
- pjmlp 7y ago
  It also means more memory being used.
  - ajconway 7y ago
    Do you mean that it tends to require using immutable data structures?
    - pjmlp 7y ago
      Yes, and that it gets generated and thrown away in each view update, even if a view diff is taken into account.