fork() creates a new process with a clone of the parent's state including its address space, file descriptors, etc. But it doesn't copy any of the other threads of a multithreaded program; the call to fork() acts much like a call to a signal handler, and in fact it is unsafe to do anything in the child process that isn't explicitly async-signal-safe.
You cannot safely call fork() from Swift[1]. See for example this past discussion about it. Oh, and this short paper from Microsoft Research.
On Darwin in particular, fork() is effectively deprecated and is only ever really seen in code that's a straight port from some flavour of UNIX. If a forked child process touches Core Foundation before calling execve() (or related), the process terminates. In the general case, a program written in Swift and running on Darwin is probably linking against Core Foundation directly or indirectly.
While I wouldn't advise the average Swift developer to go reimplementing Bundle, Bundle itself needs to look up the executable path of the current process in order to implement resource discovery. 
You can call
fork()from C/C++ in a program that also includes Swift, but only if you callexecve()(or related) immediately afterward. This is effectively howposix_spawn()is implemented on some platforms, of course. ↩︎