SPI decribes only how bits are sent/received, and doesn't prescribe any other aspects of communication except that practically, the master device is in control of when communication happens - a slave can't initiate. Beyond this, the choice of who is writing and who is reading at any given time is implementation-dependent.
In practice most simple devices will not send and receive data simultaneously, because it is simpler and more common to implement communication in the form of commands and responses - the master sends some command, and the slave responds either by replying with data or by readying it to receive some data, and these happen one after the other.
That said, the SPI devices at each end are always writing bits (even if zero) and always receiving bits (even if discarded) upon every clock signal, whether the implementations are actually using these or not.
If you want to take advantage of the full duplex nature of SPI by writing a protocol that will transmit and receive simultaneously, SPI lets you do this.
At the level of your SPI library/abstraction, your library will either provide separate methods for reading, writing, and perhaps doing both at once, or it will simply provide a method for writing and reading at the same time and it's up to you to discard or zero out the parts that are not meaningful in the protocol. Doing a read/write where you send zero is functionally the same as doing only a read, and doing a read/write where you discard what you read, is functionally the same as doing only a write.