Hello All 
The question is in the title Thank you !
@Lostania What and why do you want to slow it down. Normally you want the physics engine to run as fast as it can. To slow thing down, you can change the gravity scale using physics.gravity(.5,.5) to make gravity half as strong.
Thank you for you answer. I’m on a game where the time must slow down so I need to slow down the physics included to obtain a slow motion effect. The game is tabletop so gravity does not interfere.
@Lostania, perhaps doing physics.pause and physics.resume on alternate calls to draw might simulate what you want?
Thank you. I may investigate this idea but I have some doubt about the fluidity of the rendering with alternate pauses and resumes…
Here’s a very old comment of mine from 2014 which may still be relevant. I don’t know if Simeon ever considered the suggestion. What I’d been thinking of was like in Kerbal Space Program where you can accelerate time, but the same concept could work by setting the multiplier to 0.5 to slow physics relative to time:
Looking in the Codea runtime it looks like what it does is pass in the DeltaTime (time for the frame), then the physics engine will do a 1/60 step how ever many times it needs to catch up to the deltatime (ie if framerate is currently slower that 60fps it’ll sometimes do 2 or more steps). So it’s locked to the speed of time on the ipad.
@Simeon I guess what TLL could consider is allowing you to set a physics parameter which gives a multiplier to deltatime when it’s accumulating in the PhysicsManager. That way rather than controlling step, you’d having a setting of 1.0 ie realtime, but you could change it to 5.0 being 5x realtime etc. It’d still do physics steps at 1/60s so the accuracy would be the same, it’d just slow processing. And the current iterations feature could let you drop accuracy for speed.
Of course that’s based on the old runtimes, but I presume the new exports/Codea itself are similar under the hood.
Thank you for your proposition wich could help a lot