Chapter 11: Failed to read Info.plist of app

Hi there!

I’m trying to build the Playground project of chapter 11, but I’m not able to do it due to the following error:

error: Failed to read Info.plist of app [...]/Debug-iphoneos/RxSwiftPlayground.app

In fact, it’s true that the RxSwiftPlayground doesn’t have an Info.plist file. But until now, I haven’t had that kind of problem when I needed to run the previous playgrounds.

Does anyone else having this problem? Have you been able to solve it?

Thanks in advance! :+1:

Maybe @scotteg can help ?

Thanks @icanzilb for your concern, but I’ve been able to solve it doing nothing special… :sweat_smile:

Now I can run the Playground of Chapter 11 without problems. All I had to do was change the target device to an iOS simualtor that I haven’t used yet with the RxSwift project. That’s so weird :thinking:

Have a nice day!

Interesting … maybe was something to do with the device derived data? Did you try cleaning up the derived data folder before trying a different simulator?

On page 224 of this book: “One-shot or repeating timers” talking how to use “timer” operator. I dont understand the reason why if i set the param: “due” to 2.0 and set the param “delayInSeconds” to 0.0 but after 4.0s, the first element of the delayedTimeline emitted( I think after 2.0s). Pls explain to me! Thanks in advance!

Maybe @fpillet can answer this?

Hi @sistemas, I encountered the same issue when I opened this project after running pod install.

After deleting derived data (steps 1-6 here), I was able to build successfully and run the playground.

@doquanghuy91 there’s a completely rational explanation to this behavior, which is correct with regards to how elements are being emitted by the source observable. Let me elaborate:

  • the source observable sequence is a timer that emits once every second.
  • DispatchSource.timer is configured to fire once every second. Note that (as you can examine in the Sources > Timer.swift file of the playground), it starts firing IMMEDIATELY. Which means that the first element is emitted immediately
  • the example you modified uses a timer(_:scheduler) operator to delay initial observation of the source sequence. Since you give it a 2 second dueTime, it waits two seconds before it emits something that goes into flatMap

So let’s summarize. Timer starts immediately by emitting “1”. Then you set up a timer that waits two seconds before it starts observing the sequence. When exactly two seconds have passed, element “3” has already been emitted by the sequence. At this point, your flatMap returns a zero-delay sequence which immediately starts tracking the source observable. Therefore, the first element that the delayed sequence receives is “4”.

It’s all a matter of delicate synchronicity and order of things. I understand that the results can be misleading, but they are totally correct in this context.

Hope this answers your question!