The behaviour you are seeing is correct. The didWriteValueForCharacteristic method confirms that the characteristic was written, but it is the peripheral itself that is the 'keeper' of the characteristic value. Core-Bluetooth won't have a new value in the characteristic until it is retrieved from the peripheral, either in response to a read request or a notify if you have subscribed to the characteristic.
From your comment it seems that the old-behaviour was to "short-circuit" the process and expose the new value immediately - This is dangerous because the peripheral may make other updates to the characteristic, so you shouldn't rely on the data without performing a read.