
Using Apple's Combine Framework - aaronbrethorst
https://heckj.github.io/swiftui-notes/
======
skohan
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
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.

~~~
DrScientist
Doesn't an application still have a state, even if you don't store/manage it
explicitly?

Isn't a program more understandable if that state is sometimes made explicit
rather than implicit?

Also if your goal is 'functional purity' then you might want to read this
article from ten years ago.

[https://prog21.dadgum.com/55.html](https://prog21.dadgum.com/55.html)

~~~
ajconway
The state is there, of course. The goal here is to minimize the amount of
state the code has access to at any particular time.

Functional purity is not the goal, it's just one way to reduce state.

~~~
DrScientist
So you still have state, but you can't get at it because it's been moved from
the heap to the call stack?

I'm not sure that makes programs:

1\. Easily evolve-able.

2\. Easy to understand.

Well managed accessible state can be greatly simplifying.

In my view the goal should be simple understandable code, not a meta-goal like
removing all accessible state.

~~~
bradstewart
> Well managed accessible state can be greatly simplifying.

Absolutely--and functional programming is one way to achieve that. From the
perspective a given function, all "state" is captured in its inputs and
outputs. You know exactly what existing state can be used by the function
(inputs) and exactly what state can be generated by the function (outputs)
simply from looking at the signature.

~~~
DrScientist
I'm talking about the difficultly of reasoning about high level application
state when it isn't explicit.

To take a low level example - sorting a list efficiently is easy with
imperative programming and mutable state ( Note you can still encapsulate that
state within a object - it doesn't need to be global ).

On the other hand took about 20 years before somebody worked how to do it
reasonably with a functional approach.

Being obsessive about a pure functional approach and/or having a holy war
against heap managed state is a mistake in my view.

Functional approach is a tool in the toolbox, not a golden hammer.

~~~
bradstewart
Totally agreed. Being obsessive about (almost) anything in software is a
recipe for pain.

------
mrtksn
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
Apple is very good about getting iPhone users upgraded.

[https://gs.statcounter.com/ios-version-market-
share/mobile-t...](https://gs.statcounter.com/ios-version-market-share/mobile-
tablet/worldwide)

If you’re new to iOS or don’t support a large audience, within 6 months most
people will be using iOS 13.

~~~
skohan
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.

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

~~~
langitbiru
That's my question as well. Should I learn both technologies for greenfield
projects or just use Combine?

~~~
hamdshah
Combine is only iOS-13 If you wanna support any OS before that you have to use
RxSwift for that

