Reactivecocoa: Question: Release date

[v-silin]

Hi, I love ReactiveCocoa.

I'm annoying, sorry guys, but could you estimate release date for Reactive(Cocoa/ObjC/Swift/ObjCBridge) that can be used with Swift 3.0 ? I using swift, and my current project deeply integrated with ReactiveCocoa (approximately 70-80% like MvvM based on UIKit and RAC, API communications, in-App communications etc.), so it's very critical for me to have up to date and ready to use awesome tool called ReactiveCocoa.

Best regards,
Vasili Silin.

[mdiep]

This project is entirely volunteer driven, so it's impossible to say. I don't think I can even get a benefit.

But since RAC 4.2.2 is compatible with Swift 2.3, you can use it with Xcode 8 and shouldn't be blocked from shipping your app. (You might be blocked from moving to Swift 3, but that's just an inconvenience.) If you _must_ be on Swift 3, then you can probably use RAC and related repos as they exist on their master branches today. But be aware that there will probably be some breaking changes.

[v-silin]

Ok, got it.

I am ready to help and be volunteer, if it will speed up project.

I can help with a lot of things. Please, write me on email if you decide to accept my help. I'll share with you more information about myself through email.

[liscio]

Yeah, I'm in the same boat with a few shipping apps that use RAC/etc. but I have successfully managed to pull in ReactiveSwift, ReactiveCocoa, etc. as dependencies on my own development branch. It takes some effort to keep on top of things as they're moving quickly, but I recommend the following tips to keep yourself from going mad (assuming you're using Carthage):

Step 0: move your code to Xcode 8 using Swift 2.3 and the latest released version of your dependencies

This will keep you from having to dig out Xcode 7.x every time you have to ship a maintenance or other update in the meantime before your Swift 3 port is ready. It will also make the Swift 3 port a little bit easier, because you will have some Swift deprecation warnings you can take care of while they're still easy to fix.

Step 1: Add the new dependencies that support Swift 3

Point at the master (or other) branches of your dependencies in your Cartfile, and make sure carthage builds everything fine when you run carthage update. This may not work immediately, and you can burn a lot of time "playing detective" to find the appropriate branches.

That said, I'd be surprised if you still had some repos that don't have easy-to-find Swift 3 support in a branch or fork.

Step 2: Pin these dependencies at a specific revision, and not master

Once you've got a building set of dependencies, copy the revisions from Cartfile.resolved to your Cartfile.private and Cartfile as appropriate. Do not specify master or any other branch specifier in your Cartfile, as this will be the source of much grief.

Why pin the dependencies? Well, if you're like me and you also have your own dependency libraries that are being ported, then you will find that carthage update will put you into a seemingly endless loop of repeatedly breaking your code while development is happening.

Note: You should _also_ pin those dependency revisions for RAC/etc in your private frameworks during development, and if you do have your own private frameworks you should have started with Step 1 in those frameworks…

Step 3: Port your code over to Swift 3

Good luck! It's not going to be as straightforward as you hoped, and Reactive{Cocoa,Swift} have a bunch of their own API changes that'll take some time and thought to integrate.

Step 4: Move your Cartfile's specification of the pinned revision back to master

Re-run the carthage update command, and then go back and repeat Step 2.

Step 5: (TBD - Once ReactiveCocoa is all released) Return your Cartfile to pointing at the Swift 3 releases

At this point you should be good to move forward. Even with alpha/etc releases, you probably should stick to pinned revisions for a little while.

Also? There's really nothing that guarantees that an "official release" is going to be perfectly stable (or even usable in your specific application) for a little while. As far as I can tell, much of the API churn has been done without extensive consumption of the API in large projects.

So with that said, there's nothing wrong with shipping this current master revisions in an application of any size. If it passes all your testing, and has no noticeable performance issues or other regressions, then it's good to go. It's not like @mdiep or another maintainer hitting the "release" button is going to magically bless the binary as being perfect. :)

The above is where your help comes in. Consume the APIs, test the library in its current form, and report (or better, fix!) the issues you come across in your applications.

Hope this helps!

[v-silin]

Thank you. Yes, this will help a lot. :)