In this answer How to make RACSignal to become hot?, @erikprice explains hot and cold signal
A "hot signal" is a signal that sends values (and presumably does work) regardless of whether it has any subscribers. A "cold signal" is a signal that defers its work and the sending of any values until it has a subscriber. And a cold signal will perform its work and send values for each subscriber.
I ask if someone can demonstrate examples of hot and cold signals, so that it will be clearer
A hot signal is considered to be a signal that sends values regardless of whether it has any subscribers
I am using a hot signal for monitoring network reachability. A button action realized through RACCommand is another example of hot signal.
A "cold signal" is a signal that defers its work and the sending of any values until it has a subscriber.
This one is very well demonstrated by making AFNetworking reactive. Create a method that returns a signal representing a request. Whenever you subscribe to that signal, the networking request is performed. The subscriber is being sendNext: and sendCompleted when request is successful and sendError: when request fails.
I find the RAC 3 Changelog to be useful, too
Hot signals are now Signals
In the terminology of RAC 2, a “hot” RACSignal does not trigger any side effects when a -subscribe… method is called upon it. In other words, hot signals are entirely producer-driven and push-based, and consumers (subscribers) cannot have any effect on their lifetime.
This pattern is useful for notifying observers about events that will occur no matter what. For example, a loading boolean might flip between true and false regardless of whether anything is observing it.
Concretely, every RACSubject is a kind of hot signal, because the events being forwarded are not determined by the number of subscribers on the subject.
Cold signals are now SignalProducers
In the terminology of RAC 2, a “cold” RACSignal performs its work one time for every subscription. In other words, cold signals perform side effects when a -subscribe… method is called upon them, and may be able to cancel in-progress work if -dispose is called upon the returned RACDisposable.
This pattern is broadly useful because it minimizes unnecessary work, and allows operators like take, retry, concat, etc. to manipulate when work is started and cancelled. Cold signals are also similar to how futures and promises work, and can be useful for structuring asynchronous code (like network requests).
I have written Push vs Pull Signal which basically reveal how Push vs Pull Signal get implemented, in Swift 2