Playgrounds get stuck "Running..."

It may help to set manual execution mode (the square at the bottom).

Hi Mic,

Same issue for me, my Playground get stuck as soon as an error comes in as:

error: Execution was interrupted, reason: signal SIGABRT.

The process has been left at the point where it was interrupted, use "thread return -x" to return to the state before expression evaluation.

Need to quit and relaunch and at relaunch long time with Lauching Simulator...

Really disappointing.

Could test 9.4 beta2:

The feature is broken on 9.4 Beta 2 as well! I've attempted to use the beta in hopes the problem would have been rectified but much like iTunes, xCode's playground has quickly become the step-child of Apples pet projects. Sigh!

Playgrounds working again for me in Version 9.3.1 (9E501).

Would have to agree with you Mic - the playground in 9.3.1 hangs on "Running" incesantly and when I installed the 9.4 beta guess what - same thing. Was excited to use the playground yet it 100% useless and a waste of time.

Did you check whether XCode 10 solves those issues ?

Under Xcode 10 I can't execute anything at all. I click the play button, it says "Running" then it just stops - nothing happens. Is anyone else experienceing this?

Yep, with Xcode 9.4 on High Sierra latest versions, I'm trying to prototype some SceneKit code in a macOS playground. My machine is a MacbookPro Retina (early 2013), 8gb ram.

It's so unstable I have to restart Xcode (if it hasn't crashed and restarted itself) at least once an hour.

I find that:

1. Saving files triggers crashes.

2. Editing anything other than the main playground entry code does not cause the playground to recompile automatically or quickly.

3. If an error exists in anything other than the main playground entry code, you get this stupid modal dialog on the screen with "The auxiliary source module did not compile successfully." as the message. Just show me the error messages inline like any other compilation issue, thanks. And when I have two displays, that dialog insists on showing on the primary display, not the one with Xcode (which I run on the larger, secondary display).

4. Code completion both automatic, and via the ESC key does not work in anything other than the main playground entry code.

5. I see a lot of these SIGTERM errors after watching the beachball for 30 seconds.

"error: Execution was interrupted, reason: signal SIGTERM.

The process has been left at the point where it was interrupted, use "thread return -x" to return to the state before expression evaluation."

Honestly, the whole "swift" experience is painful. I can try reworking my playground into a mac app to see if it's more stable. God forbid kids actually try to learn with this stuff. It will turn people away.

[EDIT] I've just taken my code out of the playground and copied it into a new macOS.game project. Same code with the only tweaks being the game view initialisation stuff that had to change slightly. Now, the thing runs first time, every time. So I've wasted all this time on Playgrounds which are slower to compile, less intuitive to use, can't be debugged, etc when I could simply be running the app natively and quickly on the mac.

I'm having the same problem with Xcode 10.1 on MacBook Air. Stuck on "Running" and code will not execute. Even the tutorial playgrounds by Apple won't run. Does anyone have a fix for this?

Did you try changing to manual execution ?

I found that if I strart the day (before I open any apps) with a playground app that I am working on it loads and runs after a bour 3 - 4 mins and remains stable after that.

If I try to open a playground with xCode and the xCode Simulator open playground sticks in the "Running" mode forever!

Same here in Xcode 11.4. It's a even a macOS playground so I don't think it needs a Simulator. Playgrounds are such a cool idea, but I don't think I've gotten one to work for more than 5 minutes since they were released in 2014. Apparently there is nothing I can "kill" in the Activity Monitor app? I just have to restart Xcode. It ends up being easier to write command line test programs or small iOS apps.