What was the motivation to create a closed source reactive programming framework, when RxSwift is already mature, established, and open-source?
Rx also follows a cross platform API, that's familiar to people in C#, Java, Python, Ruby, JS, and a whole bunch of other languages with Rx implementations. (And don't worry, it's not the usual case of "cross platform means everything is lowest-common-denominator, the frameworks are tweaked from language to language to embrace language paradigms)
RxSwift is large and complicated. I understand your question, but I happen to be glad they went with something else to solve a narrow requirement. Based on my admittedly-brief look at the API, it could serve as a foundation for a future version of RxSwift, instead of remaining as a reinvention.
Perhaps, but one of its bigger appeals (IMO) is that unifies multiple systems:
NSNotificationCenterIt also offers a testing framework, which Combine doesn't. You can test async using "virtual time", that lets you write declarative test cases that don't require waiting on wall clock time.
Another benefit is that supports old OSes, so it has utility to developers who can't use SwiftUI (which is only available on the newest OS version)
I completely agree that all those points make RxSwift attractive for developers. I still understand Apple's reluctance to sherlock the project, as they only implemented a small part, and they probably don't want to inflict RxSwift on every Apple-platform Swift GUI Developer.
I also have a very small Observables framework, very roughly modeled on RxSwift. It's very bare-bones, but avoids dragging in frameworks larger than my app's codebase.
As far as I know the Rx derived systems don’t implement back pressure, while Combine appears to. Personally I find this feature important.
Ah, that's compelling.
FWIW, I've long wanted to start using more reactive programing and so have dabbled with RXSwift and ReactiveSwift. However I've never been able to get past dabbling due to difficulties integrating it into existing projects. If you can go all-in, it seems wonderful! However the on-boarding process is far from simple due to the specialized verbiage and APIs and (for me) it became an all-or-nothing situation.
I had a lot of difficulty adding it to existing codebases without completely re-architecting how they worked and ending up wanting/needing to rewrite the entire thing. Accessing the power it provides seems to inevitably result in a draconian takeover of your codebase.
Combine, at least at first/second glance, seems a bit more constrained and focussed. I'm optimistic it will be easier to add to existing/new portions of a codebase and allow for gradual transformation, rather than a hostile takeover 
Side note: I'm guessing it's supposed to be Combine, but does anyone else keep pronouncing it COM-bine in their head? I can't stop 
It's definitely not just you 
And combine do that with much more. This is not yet available, but according to Xcode release notes, it will include a lot of subsystems:
The Foundation integration for the Combine framework is unavailable. The following Foundation and Grand Central Dispatch integrations with Combine are unavailable: KeyValueObserving, NotificationCenter, RunLoop, OperationQueue, Timer, URLSession, DispatchQueue, JSONEncoder, JSONDecoder, PropertyListEncoder, PropertyListDecoder, and the @Published property wrapper. (51241500)
Nothing is perfect in this world.
Nope. But it's open source, so they're welcome to contribute to it. Which would be cool to see, given how much their competitors have stepped up their open-source-game.
Two of the biggest issues I've had using RxSwift in non-trivial projects are:
Call stacks become much less useful, since there is so much indirection inside the library, which makes debugging painful (especially for code I didn't write).
There's a lot of boilerplate and manual bookkeeping (e.g. DisposeBag).
If Combine addresses these issues, it would make Reactive-like programming a lot more palatable to me.
I haven't had a chance to use Combine yet, so could you share your impressions with it? What are its call stacks like?
Property wrappers could be employed to remove the need for dispose bags in most circumstances. I suspect that's what Combine is doing for managing subscription lifetimes. They had a head start on that one (given that they had access to this secretly implemented feature before it formally finished the evolution process), but it's not something that couldn't be improved in Rx.
It's the "we'll make our own" attitude that bothering me, compounded with the fact that the end result is closed source and platform locked. They could have just improved Rx to fit their needs, just as they did with improving Swift for SwiftUI.
I haven't worked with it either. I was simply pointing out some issues with RxSwift which, to me, are substantial enough to warrant building another tool rather than building on top of Rx.
Does anyone know if there is any chance to see combine becoming open source at some point ?
Being open source is one of the great quality of Swift, I do believe that it is a key factor of the rapid growth of the language.
SwiftNIO, being also open source, adds to the credibility of the language, notably on the server side.
Having combine open sources would certainly add one more layer of attractiveness to the swift ecosystem.
I consider the arrival of one new proposal in the swift Rx world a good piece of news. But please, Apple, make it open source ! It would benefit you as much as the whole swift community.
Both Combine and SwiftUI look like projects that could have a really positive impact for Swift if they were open sourced! Like others here I also hope Apple will do this!
Do you have that small project you use somewhere on github? I have the same concerns with using RxSwift. A bit too large for my purposes
What exactly do you mean by "a bit too large"? Is it a matter of binary size?
In RxSwift disposeBags reduce the amount of bookkeeping. If your viewController subscribes to some event, you generally want to stop observing that even when your viewController goes away.
You could save a reference for each subscription and have each automatically deinit, but defining each one of those variables on your vc increases the amount of code need as opposed to just throwing each subscription into a bag and letting it manage the lifecycle for you.
If you want to reduce the number of .disposed(by: disposeBag) boilerplate, use the new variadic insert method. (RxSwift and the Secret of the Variadic DisposeBag | by Michael Long | Medium)
Yes we will be forced to use 2 reactive frameworks within our projects even if you decide to use Rx you will be forced to use combine on the client side as more and more frameworks within the swift ioS /Mac os x eco system will depend on and add it to there public api. So if you make a choice to use Rx so you can use on server side and client side you will still need to use combine. I think this is a bad a decision, companies say look we are open source and that its all for community when it's not. What happens when Apple start using combine within the swift standard library are we to have two ??? . I have no problem apple having and using closed source software but building a reactive framework that pretty much over the next two years there wont be a framework that dose not expose combine from their public api and then limiting to their own platform. Is a big mistake and the reason we will need to be bridging between combine and what ever reactive framework you chose to use Apple for what ever reason put a lot of effect not to referrer to combine as a reactive framework so dose it follow the reactive tck. Can we use in combination with other reactive framework, I can see this making me have to write more code for my project not less.