A Swift based Future/Promises Library for IOS and OS X.

Related tags

EventBus FutureKit
Overview

FutureKit for Swift

CocoaPods Compatible Carthage Compatible License Platform Twitter

A Swift based Future/Promises Library for IOS and OS X.

Note - The latest FutureKit is works 3.0

For Swift 2.x compatibility use version 2.3.0

FutureKit is a Swift implementation of Futures and Promises, but modified specifically for iOS/OSX programmers. You can ready the wikipedia article here: http://en.wikipedia.org/wiki/Futures_and_promises

FutureKit uses Swift generic classes, to allow you to easily deal with asynchronous/multi-threaded issues when coding for iOS or OSX.

  • is 100% Swift. It currently supports Swift 2.x/3.0 and Xcode 8+. For Swift 2.x compatibility, use the version 2.3.0.

  • is type safe. It uses Swift Generics classes that can automatically infer the type you wish to return from asynchronous logic. And supports both value and reference Swift types (Both 'Any' types, and 'AnyObject/NSObject' types.)

  • Is Swift error handling friendly. All FutureKit handler methods can already catch and complete a Future using any ErrorType. So you don't need to wrap your code with 'do/try/catch'.

  • FutureKit in Swift is designed to simplify error handling, allowing you to attach a single error handler that can catch any error that may occur. This can make dealing with composing async operations much easier and more reliable.

  • uses simple to understand methods (onComplete/onSuccess/onFail etc) that let's you simplify complex asynchronous operations into clear and simple to understand logic.

  • is highly composeable, since any existing Future can be used to generate a new Future. And Errors and Cancelations can be automatically passed through, simplifying error handling logic.

  • Super easy cancelation composition (which is a fancy way to say cancel works when you want it to automatically). Future's are designed so there is never any confusion about whether an asynchronous operation completed, failed, or was canceled. And the consumer has full control over whether he needs to be notified that the operation was canceled or not. (0% confusion about whether your completion blocks will get called when the operation is cancelled).

  • works well editing code within Xcode auto-completion. The combination of type-inference and code-completion makes FutureKit coding fast and easy.

  • simplifies the use of Apple GCD by using Executors - a simple Swift enumeration that simplifies the most common iOS/OSX Dispatch Queues (Main,Default,Background, etc). Allowing you to guarantee that logic will always be executed in the context you want. (You never have to worry about having to call the correct dispatch_async() function again).

  • is highly tunable, allowing you to configure how the primary Executors (Immediate vs Async) execute, and what sort Thread Synchronization FutureKit will use (Barriers - Locks, etc). Allowing you to tune FutureKit's logic to match what you need.

What the Heck is a Future?

So the simple answer is that Future is an object that represents that you will get something in the future. Usually from another process possible running in another thread. Or maybe a resource that needs to loaded from an external server.

let imageView : UIImageView =  // some view on my view controller.
let imageFuture : Future<UIImage> = MyApiClass().getAnImageFromServer()

There are few things that are interesting. This object represents both that an image will arrive, and it will give me universal way to handle failures and cancellation. It could be that MyApiClass() is using NSURLSessions, or AlamoFire, combined with some kinda cool image cache based on SDWebImage. But this viewController doesn't care. Just give me a Future<UIImage>. Somehow.

now I can do this:

imageFuture.onSuccess(.Main) {  image  in
    imageView.image = image
}

This is a quick way of saying "when it's done, on the MainQ, set the image to an ImageView.

Let's make things more interesting. Now your designer tell you he wants you to add a weird Blur effect to the image. Which means you have to add an UIImage effect. Which you better not do compute in the MainQ cause it's mildly expensive.

So know you have two asynchronous dependencies, one async call for the network, and another for the blur effect. In traditional iOS that would involve a lot of custom block handlers for different API, and handling dispatch_async calls.

Instead we are gonna do this.

let imageFuture : Future<UIImage> = MyApiClass().getAnImageFromServer()
let blurImageFuture =  imageFuture.onSuccess(.UserInitiated) { (image) -> UIImage in
     let blurredImage = doBlurEffect(image)
     return blurredImage
}

blurrImageFuture is now a NEW Future. That I have created from imageFuture. I also defined I want that block to run in the .UserInitiated dispatch queue. (Cause I need it fast!).

blurImageFuture.onSuccess(.Main) { (blurredImage) -> Void in
     imageView.image = blurredImage;
}

Or I could rewite it all in one line:

MyApiClass().getAnImageFromServer()
     .onSuccess(.UserInitiated) { (image) -> UIImage in {
                    let blurredImage = doBlurEffect(image)
                    return blurredImage
     }.onSuccess(.Main) { (blurredImage) -> Void in
                     imageView.image = blurredImage;
     }.onError { error in
                 // deal with any error that happened along the way
     }

That's the QUICK 1 minute answer of what this can do. It let's you take any asynchronous operation and "map" it into a new one. So you can take all your APIs and background logic and get them to easily conform to a universal way of interacting. Which can let you get away with a LOT of crazy asynchronous execution, without giving up stability and ease of understanding.

Plus it's all type safe. You could use handler to convert say, an Future<NSData> from your API server into a Future<[NSObject:AnyObject]> holding the JSON. And than map that to a Future<MyDatabaseEntity> after it's written to a database.

It's a neat way to stitch all your Asynchronous issues around a small set of classes.

Then what is a Promise?

A promise is a way for you write functions that returns Futures.

func getAnImageFromServer(url : NSURL) -> Future<UIImage> {
    let p = Promise<UIImage>()

    dispatch_async(...) {
         // do some crazy logic, or go to the internet and get a UIImageView.  Check some Image Caches.
         let i = UIImage()
         p.completeWithSuccess(i)
    }
    return p.future
}

A Promise is a promise to send something back a value (of type T) in the future. When it's ready.. A Promise has to be completed with either Success/Fail or Cancelled. Don't break your promises! Always complete them. And everyone will be happy. Especially your code that is waiting for things.

But it also means the API doesn't really need to bake a whole bunch of custom callback block handlers that return results. And worry about what dispatch_queue those callback handlers have to running in. Do you dispatch to mainQ before you call your callback handlers? Or after? Nobody seems to agree.

But the Future object already offers a lot of cool built ways to get told when data is ready and when it fails. And can handle which GCD queue is required for this reply.

The api just has to emit what he promised. The Future will take care of getting it to the consumer.

And since Futures can be composed from Futures, and Futures can be used to complete Promises, it's easy to integrate a number of complex Async services into a single reliable Future. Mixing things like network calls, NSCache checks, database calls.

It also "inverts" the existing dispatch_async() logic. Where first you call dispatch_async(some_custom_queue) and THEN you call some api call to start it working.

func oldwayToGetStuff(callback:(NSData) -> Void) {
    dispatch_async(StuffMaker().custom_queue_for_stuff)  {

        // do stuff to make your NSData
        let d = StuffMaker().iBuildStuff()

        dispatch_async(dispatch_get_main()) {
            callback(d)
        }
    }
}

notice how I forgot to add error handling in that callback. What if iBuildStuff() times out? do I add more properties to the callback block? add more blocks? Every API wants to do it different and every choice makes my code less and less flexible.

class StuffMaker {
    func iBuildStuffWithFutures() -> Future<NSData> {
        let p = Promise<NSData>()
        dispatch_async(self.mycustomqueue)  {
             // do stuff to make your NSData
            if (SUCCESS) {
                let goodStuff = NSData()
                p.completeWithSuccess(goodStuff)
            }
            else {
                p.completeWithFail(NSError())
            }
        }
        return p.future()
    }
}

Notice we are now calling StuffMaker() directly, without having to dispatch first. And I'm not calling dispatch_async() AGAIN before I call the callback block. I will let the consumer of the Future decide where he wants his handlers to run.

Now you 100% guarantee that the code you want will ALWAYS run in the dispatch_queue you want. It just returns a Future object.

Documentation

FutureKit documentation is being written as Xcode Playgrounds. The best way to start is to open the FutureKit.workspace and then opening the Playground inside. (If you open the Playgrounds outside of the workspace, then FutureKit module may not import correctly). The Xcode Playgrounds probably require Xcode 6.3 (in order to see the Markup correctly)

If you are impatient, or not near your copy of Xcode, you can try to read the first intro "raw" playground here: https://github.com/FutureKit/FutureKit/blob/master/FutureKit-Future.playground/Contents.swift

Help out!

I would love it to get feedback! Tell me what you think is wrong. You can follow @swiftfuturekit to get announcements (when we make them).

Comments
  • Crash in OSSpinLockSynchronization

    Crash in OSSpinLockSynchronization

    This is an unreproducible one-off crash, so I just wanted to leave it here for future reference. It occurred in the wild for a user and was reported via Fabric.io.

    From the mangled symbols it looks like it might be the UnSafeMutableContainer<OSSpinLock> property self.lock inside OSSpinLockSynchronization which is causing this issue.

    The application was calling .onSuccess(.UserInteractive) on a Future from the main thread. Device: non-jailbroken iPhone running iOS 9 FutureKit version: 1.2.0

    This is the top of the call stack. The rest is application code + system libraries.

    EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x50000000139032db
    Thread : Crashed: com.apple.main-thread
    0  FutureKit                      0x1009c6d40 _TFC9FutureKit25OSSpinLockSynchronization12synchronizedurfS0_FFT_q_q_ + 80
    1  FutureKit                      0x1009c6e58 _TFC9FutureKit25OSSpinLockSynchronization13lockAndModifyurfS0_FT13waitUntilDoneSb11modifyBlockFT_q_4thenGSqFq_T___T_ + 128
    2  FutureKit                      0x1009c7110 _TFC9FutureKit25OSSpinLockSynchronization18lockAndModifyAsyncurfS0_FTFT_q_4thenFq_T__T_ + 144
    3  FutureKit                      0x1009c7b98 _TTWC9FutureKit25OSSpinLockSynchronizationS_23SynchronizationProtocolS_FS1_18lockAndModifyAsyncu__Rq_S1__fq_FTFT_qd__4thenFqd__T__T_ + 88
    4  FutureKit                      0x10098511c _TFC9FutureKit6Future10onCompleteu__rfGS0_q__FTOS_8Executor5blockFzT6resultGOS_12FutureResultq___GOS_10Completionqd____GS0_qd___ + 568
    5  FutureKit                      0x100985f24 _TFC9FutureKit6Future9onSuccessu__rfGS0_q__FTOS_8Executor5blockFzq_GOS_10Completionqd____GS0_qd___ + 200
    6  FutureKit                      0x100987400 _TFC9FutureKit6Future9onSuccessu__rfGS0_q__FTOS_8Executor5blockFzq_GS0_qd____GS0_qd___ + 200
    
    opened by heiberg 8
  • Multiple futures

    Multiple futures

    Can I make Promise/Future of multiple futures, lets say I have 2 API calls one returning some mapped object like Article and the other simple Integer. How do I combine those two to single Future, cause I wanna do something when both of these are done :)

    opened by zdnk 6
  • Remove OSSpinLockSynchronization

    Remove OSSpinLockSynchronization

    Summary

    This pull request removes OSSpinLock as a supported synchronization mechanism.

    Additionally, the default locking strategy is changed from OSSpinLock to PThreadMutex.

    Motivation

    There's a post on the swift-dev mailing list from Dec 14, where John McCall of Apple explicitly states that using OSSpinLock on iOS is illegal.

    Later, David Smith (also from Apple) stated on Twitter that this is not confined to iOS but also affects OS X due to the throttling and priority shuffling done on the new 12" MacBook.

    Apparently the issue is that lock acquisition from a high priority thread may fail indefinitely in case of a priority inversion, where the lock is already held by a low priority thread. The spinning done by the higher priority thread to acquire the lock can prevent the low priority thread from ever completing its work and releasing the lock. The result is effectively a deadlock.

    A more in depth discussion on the topic can be found here.

    PThreadMutex was chosen as the new default as it is reportedly the underlying mechanism used to implement NSLock, but experimentally it has a slightly smaller overhead.

    Implications

    Existing code relying on the default locking strategy is likely to see a minor performance hit on the locking/unlocking operations.

    opened by heiberg 5
  • Build error on Xcode 9 Beta 3

    Build error on Xcode 9 Beta 3

    I am using Carthage dependency to load FutureKit in our project. However, during build phase it is failing with following error on Xcode 9 Beta 3. (Screenshot attached).

    Adding following line in the Error extension seems to be fixing the build error.

    var userInfo: [AnyHashable: Any] { return [:] }
    

    Just want to confirm if this is a legit error and then we can put PR to fix it screen shot 2017-07-27 at 4 52 08 pm

    opened by jayesh15111988 4
  • Never-ending process when building or archiving.

    Never-ending process when building or archiving.

    Hi

    I added FutureKit to my project manually and it works great when i build it and test, but whenever i try to archive and it gets to FutureKit iOS it spins up a swift process taking up 99% CPU and never gets further than in building than "Compiling Swift source files". I also tried just opening the project and running it in order to build the framework and just import that, but the same thing happens. The same thing also happens if i use carthage.

    opened by gundlev 4
  • Allow futurekit to build via carthage with Xcode 9

    Allow futurekit to build via carthage with Xcode 9

    Currently when I try to build FutureKit 3.0.0 with carthage and Xcode 9, I get build errors (see this gist for the build output). We want to experiment with xcode 9 but can't until this is resolved. Is this just a project settings tweak or is there something more fundamental that the Xcode 9 compiler in swift 3 mode expects that futurekit isn't doing?

    opened by klundberg 3
  • Exclude invalid paths in Package.swift

    Exclude invalid paths in Package.swift

    Fixed the following issues when using FutureKit as a Swift Package Manager Package:

    error: the module at Packages/FutureKit-3.0.0/docs does not contain any source files
    fix: either remove the module folder, or add a source file to the module
    
    error: the module at Packages/FutureKit-3.0.0/FutureKit contains mixed language source files
    fix: use only a single language within a module
    
    error: the module at FutureKit iOS Testing AppTests has an invalid name ('FutureKit iOS Testing AppTests'): the name of a non-test module has a ‘Tests’ suffix
    fix: rename the module at ‘FutureKit iOS Testing AppTests’ to not have a ‘Tests’ suffix
    
    error: the module at FutureKit iOS Tests has an invalid name ('FutureKit iOS Tests'): the name of a non-test module has a ‘Tests’ suffix
    fix: rename the module at ‘FutureKit iOS Tests’ to not have a ‘Tests’ suffix
    
    error: the module at FutureKit OSX Tests has an invalid name ('FutureKit OSX Tests'): the name of a non-test module has a ‘Tests’ suffix
    fix: rename the module at ‘FutureKit OSX Tests’ to not have a ‘Tests’ suffix
    
    error: the module at Packages/FutureKit-3.0.0/FutureKit tvOS does not contain any source files
    fix: either remove the module folder, or add a source file to the module
    
    error: the module at FutureKit tvOSTests has an invalid name ('FutureKit tvOSTests'): the name of a non-test module has a ‘Tests’ suffix
    fix: rename the module at ‘FutureKit tvOSTests’ to not have a ‘Tests’ suffix
    
    error: the module at Packages/FutureKit-3.0.0/FutureKit watchOS does not contain any source files
    fix: either remove the module folder, or add a source file to the module
    
    error: the module at Packages/FutureKit-3.0.0/FutureKit.xcworkspace does not contain any source files
    fix: either remove the module folder, or add a source file to the module
    
    error: the module at FutureKitTests has an invalid name ('FutureKitTests'): the name of a non-test module has a ‘Tests’ suffix
    fix: rename the module at ‘FutureKitTests’ to not have a ‘Tests’ suffix
    
    opened by andystanton 3
  • Cancellation deadlocks

    Cancellation deadlocks

    I'm seeing a pattern of deadlocks when attempting to cancel futures via a cancellation token that I can't make sense of.

    I managed to boil it down to a pretty simple reproduction. Maybe I'm doing something wrong here, but I'm not sure what it is.

    Let's start out with a utility function creating a simple, cancellable, long-running future:

    func createFuture() -> Future<String> {
        let p = Promise<String>()
        p.automaticallyCancelOnRequestCancel()
        Executor.Default.executeAfterDelay(10) {
            p.completeWithSuccess("Done")
        }
        return p.future
    }
    

    This future will attempt to complete after 10 seconds.

    In the following we'll try to cancel this future after 1 second.

    Works fine

    let future = createFuture()
    let token = future.getCancelToken()
    Executor.Default.executeAfterDelay(1) {
        token.cancel()
    }
    

    This works as expected. The future is cancelled after 1 second, and completeWithSuccess has no effect when that block runs after 10 seconds.

    Deadlock 1

    If we change the executor to .Main then the call to token.cancel() never completes. The main thread is deadlocked.

    let future = createFuture()
    let token = future.getCancelToken()
    Executor.Main.executeAfterDelay(1) {
        token.cancel() // NEVER RETURNS
    }
    

    My attempts at troubleshooting:

    It seems that token.cancel() goes through the onCancel handler set when the token was issued. This handler calls Future._cancelRequested with a synchronization object. This synchronization object is equal to future.synchObject and was given to the token when it was issued. We lock the object and proceed with the cancellation.

    Because we used automaticallyCancelOnRequestCancel the handler attempts to complete the future immediately as part of the cancellation.

    It ends up invoking future.completeAndNotify() which then tries to lock future.synchObject again. But we're already inside a lockAndModify on that object from the token.cancel() call, and so we have a deadlock.

    Deadlock 2

    Now let's go back to the cancellation which worked fine, invoking cancel on the .Default executor.

    But now we add an onSuccess handler to the future.

    let future = createFuture().onSuccess { _ in print("onSuccess") }
    let token = future.getCancelToken()
    Executor.Default.executeAfterDelay(1) {
        token.cancel() // NEVER COMPLETES
    }
    

    This also triggers a deadlock and token.cancel() never completes.

    Workaround

    Since it is the immediate completion of the future upon cancellation which causes the deadlock, one way to avoid this issue is to always return .Continue from the onRequestCancel of the promise. From the docs it seems this is recommend for other reasons as well.

    I don't understand what makes the first example work, while the last two deadlock.

    But it looks like I really should avoid returning .Complete(_) from onRequestCancel, which of course is what automaticallyCancelOnRequestCancel does?

    I'm not 100% sure if this is a bug or a user error.

    opened by heiberg 3
  • mapAsOptional() has impossible function signature

    mapAsOptional() has impossible function signature

    In Xcode 9 beta 1, this function no longer compiles:

        public func mapAsOptional<O : OptionalProtocol>() -> Completion<O.Wrapped?> {
    
            return self.map { v -> O.Wrapped? in
                return v as? O.Wrapped
            }
    
        }
    

    This is because when calling it there is no way to infer the generic parameter for 'O' (try it in 8.3 -- you can't actually call this function).

    Previously we would allow such definitions that cannot be called, but now we reject them. I think you can just remove the function in question, or change it to the following:

        public func mapAsOptional<Wrapped>() -> Completion<Wrapped?> {
          ...
        }
    
    opened by slavapestov 2
  • [question] flatmap for futures?

    [question] flatmap for futures?

    I was playing around with futurekit last week and ran into a weird roadblock, in that I couldn't return a future in an onSuccess block and have that future be the one that is chained on moving forward, making it effectively a flatmap operation. Is this something that was tried and just didn't work, or is this a feature that can be made to work if someone puts the time in? I wouldn't be averse to trying it out if there's no technical or other reason not to.

    Thanks!

    opened by klundberg 2
  • Third party libraries extensions

    Third party libraries extensions

    I am using some third party libraries in my projects such as Parse and Net. So I am going to write FutureKit extensions for them. Should I put these extensions inside FutureKit in some folder or should I create a different repo for them?

    opened by stanfeldman 2
  • Documentation link not working

    Documentation link not working

    opened by rockylive 0
  • FutureKit 4.0 -- working PR

    FutureKit 4.0 -- working PR

    Some changes..

    Killing some deprecated methods. Killing the NSData-Ext and NSFileManager-Ext... since they were bad examples anyways...

    Introducing Async extensions. Will be supplying some built in UIKit async extensions that wrap futures around a bunch of existing uikit methods.

    For example.. UIView.async.animate(animations:() -> Void) -> Future.. instead of UIView.animate(animations:completion:).

    (Inspired by 'reactive' extensions in ReactiveSwift..)

    REVAMP of Executor logic into 'ExecutorConvertable' protocol. All 'DispatchQueue' implement ExecutorConvertable etc. Along with NSOperationQueue, NSManagedContext, etc. Should be mostly source code compatible. Executor is now a 'struct' not an enumeration, but has static var that mirror the old enumerations. The goal is that 99% of existing code should compile exactly the same. (So far so good..).

    Revamp of FutureCache<> so it now will take any 'Hashable' key, not just AnyObject keys like NSCache does.

    Renaming CompletionType to CompletionConvertable Renaming FutureProtocol to FutureConvertable Renaming Completion to Future.Completion Rename FutureResult to Future.Result

    There is no more 'AnyFuture' protocol. It is now just a type alias for Future Introducing BaseFutureProtocol, which is a 'type-erased' version of a Future (it's a protocol that has no associated type) making it useful for when you want to create pointers and arrays of Futures with different associated types.

    planning to 'deprecate' 'FutureBatch()' in favor of direct async extensions on Swift Sequences.

    Ex: Old code:

    // Old code:
    let futures : = [asyncFunction1(), asyncFunction2()]
    let batch = FutureBatch(futures).future
    
    // new Code:
    let future = [asyncFunction1(), asyncFunction2()].async.future
    
    
    
    
    
    
       
    
    
    
    opened by mishagray 0
  • Crash in Synchronization.swift

    Crash in Synchronization.swift

    Hi, We're using FutureKit in XCode 9.1 with xcode9 branch (Swift 3.2) in an App for iOS/macOS that handles the processing of many files. Since we upgraded from XCode 8.3 (Swift 3.1) we observe a strange crash at runtime in PThreadMutexSynchronization.lockAndModify(waitUntilDone:modifyBlock:then:) [Synchronization.swift].

    This only happens sometimes (~ 1:20) and seems like some kind of race condition. We tried different synchronization flags like barrierSerial, serialQueue or NSLock but they all crash somewhere in their corresponding lockAndModify method.

    May this be caused by long Future-chains? We saw this crash in Tests where we had ~ 6000 futures chained with onSuccess/onComplete.

    As soon as we get a crash again I will attach a Screenshot of the position in Code.

    Thanks!

    opened by brickmakers 6
  • Make FutureKit build with Swift Package Manager

    Make FutureKit build with Swift Package Manager

    swift build previously did not build FutureKit with the swift package manager properly. This PR moves files around slightly so that swift build will work properly.

    I had to delete the ObjectiveCExceptionHandler code to make swift build work, since it doesn't support mixed-language targets. This class wasn't exposed anywhere in the framework that I could see, so I don't think this is a big deal.

    ~I wanted to migrate the unit tests to also work when running swift test, but those tests also include obj-c code that appears to be important to the definition of each test. It may be possible to restructure things so that they can compile, but I'm not familiar with how that could look yet.~

    I was able to get the tests to build by adding a separate swiftpm target for the BlockBasedTestCase objc code, which is imported by the unit tests. swift test will now build everything and run the requisite tests properly.

    opened by klundberg 4
  • 3.0.1 release?

    3.0.1 release?

    I'd love to have an official release with the app extension API fix, so that I can use this framework in an extension without getting a warning in xcode, and so that I don't have to point to a specific commit in my cartfile. Is this something that can be done relatively soon or are there other issues that need to be resolved before a point release first?

    Edit: I'd love for my PR #75 to be pulled in at the same time, so that swiftpm can easily build futurekit :)

    opened by klundberg 2
  • Warnings in the new XCode Version 8.3.2

    Warnings in the new XCode Version 8.3.2

    I get 6 warnings in the current version of XCode. Nothing serious as far as I can judge. But it sticks out in otherwise clean code. :o)

    Thanks for the great library and kind regards B

    opened by brassel 2
Releases(3.5.0)
Material para a apresentação da palestra "Implementando Interesses Transversais - um papo sobre arquitetura, DI e Design Patterns em Swift/iOS" no TDC Future 2021

--- title: Implementando Interesses Transversais - um papo sobre arquitetura, DI e Design Patterns em Swift/iOS author: Cícero Camargo date: Nov 30th

Cícero Camargo 2 Nov 30, 2021
Swift µframework providing Future

Future [] (https://github.com/Carthage/Carthage) Swift µframework providing Future<T, Error>. This library is inspired by the talk of Javier Soto at S

Le Van Nghia 122 Jun 3, 2021
Futures and Promises library

#PureFutures A simple Futures and Promises library. ##Installation ###Carthage Add the following in your Cartfile: github "wiruzx/PureFutures" And ru

Victor Shamanov 17 Apr 5, 2019
FutureLib is a pure Swift 2 library implementing Futures & Promises inspired by Scala.

FutureLib FutureLib is a pure Swift 2 library implementing Futures & Promises inspired by Scala, Promises/A+ and a cancellation concept with Cancellat

Andreas Grosam 39 Jun 3, 2021
⚡️ Lightweight full-featured Promises, Async & Await Library in Swift

Lightweight full-featured Promises, Async & Await Library in Swift What's this? Hydra is full-featured lightweight library which allows you to write b

Daniele Margutti 2k Dec 31, 2022
A promises library written in Swift featuring combinators like map, flatMap, whenAll, whenAny.

Promissum is a promises library written in Swift. It features some known functions from Functional Programming like, map and flatMap. It has useful co

Tom Lokhorst 68 Aug 31, 2022
Lightweight promises for iOS, macOS, tvOS, watchOS, and Linux

Futures Futures is a cross-platform framework for simplifying asynchronous programming, written in Swift. It's lightweight, fast, and easy to understa

David Ask 60 Aug 11, 2022
Write great asynchronous code in Swift using futures and promises

BrightFutures How do you leverage the power of Swift to write great asynchronous code? BrightFutures is our answer. BrightFutures implements proven fu

Thomas Visser 1.9k Dec 20, 2022
Promises is a modern framework that provides a synchronization construct for Swift and Objective-C.

Promises Promises is a modern framework that provides a synchronization construct for Objective-C and Swift to facilitate writing asynchronous code. I

Google 3.7k Dec 24, 2022
Promises for Swift & ObjC.

Promises simplify asynchronous programming, freeing you up to focus on the more important things. They are easy to learn, easy to master and result in

Max Howell 14k Jan 5, 2023
When is a lightweight implementation of Promises in Swift.

Description When is a lightweight implementation of Promises in Swift. It doesn't include any helper functions for iOS and OSX and it's intentional, t

Vadym Markov 260 Oct 12, 2022
Easy Swift Futures & Promises.

❗️ Archived now ❗️ Since Apple released Combine framework, I decide to archive this repo. You still can use this repo as an example of Future/Promise

Dmytro Mishchenko 40 Sep 23, 2022
Tame async code with battle-tested promises

Then Reason - Example - Documentation - Installation fetchUserId().then { id in print("UserID : \(id)") }.onError { e in print("An error occur

Fresh 963 Jan 3, 2023
A Promise library for Swift, based partially on Javascript's A+ spec

Promise A Promise library for Swift, based partially on Javascript's A+ spec. What is a Promise? A Promise is a way to represent a value that will exi

Soroush Khanlou 622 Nov 23, 2022
NotificationCenter based Lightweight UI / AnyObject binder.

Continuum NotificationCenter based Lightweight UI / AnyObject binder. final class ViewController: UIViewController { @IBOutlet weak var label: UI

Taiki Suzuki 82 Apr 4, 2021
A library that adds a throwing unwrap operator in Swift.

ThrowingUnwrap A simple package to add a throwing unwrap operator (~!) to Optionals in Swift. Import Add this to the package-wide dependencies in Pack

Allotrope 3 Aug 27, 2022
A light-weighted Promise library for Objective-C

RWPromiseKit Desiciption A light-weighted Promise library for Objective-C About Promise The Promise object is used for deferred and asynchronous compu

Canopus 113 May 4, 2022
A dead-simple abstraction over the iOS BackgroundTask API to make background tasks easy to isolate, maintain and schedule

A dead-simple abstraction over the iOS BackgroundTask API to make background tasks easy to isolate, maintain and schedule. Designed to be as lightweight and flexible as possible while tightly integrating with the system APIs. And It's built with Swift Concurrency in mind.

Sam Spencer 31 Dec 11, 2022
A Protocol-Oriented NotificationCenter which is type safe, thread safe and with memory safety

A Protocol-Oriented NotificationCenter which is type safe, thread safe and with memory safety. Type Safe No more userInfo dictionary and Downcasting,

null 632 Dec 7, 2022