Based on what I have searched, AES256 CBC seems to be slower than AES256 GCM.
However today I test both modes on iPhone 13 Pro Max simulator and they makes me confused.
With AES256 CBC, I use an obj-c library called CommonCrypto, with AES256 GCM I use the CryptoKit https://developer.apple.com/documentation/cryptokit/aes/gcm
The result was with a string of 3MB, AES256 CBC 128-bit iv took 3s to encrypt or decrypt while AES256 GCM 96-bit iv took 10s!
What could be wrong here?
First of all, AES CBC should never be slower than GCM if each AES block cipher operation takes the same time. AES-CBC only performs a XOR between the block encrypts, and XOR's are so fast that the overhead should be negligible. AES-GCM however consists of counter (CTR) mode & GMAC calculations. CTR uses a 128-bit counter (negligible) and a XOR. However, the GMAC will have to be performed on top of that. It depends on the hardware how fast a Galois multiplication is, but it can be made relatively fast on ARM.
However, a lot depends on the implementation specifics. Objective-C is very fast and using managed code / swift may introduce an overhead, even if the actual implementation is again in C. This can especially hurt you if you don't allow for a warm up time in case an interpreter is used, as some operations will only be accelerated once they have been executed a few times.
CBC is quite often supplied as a streaming implementation, which means that the memory consumption can be relatively limited. If GCM only allows for everything in memory (as you want to verify the tag anyway before using the decrypted plaintext) then this may introduce overhead as well.
Note that if the key is stored in a key store vs memory then this may also make a lot of difference. Quite often the key will use a specific trusted environment if it is present in a key store, otherwise it would need to be copied out of the trusted environment to be used, which largely negates any benefit of having the trusted environment in the first place.
Finally, simulators are not emulators; they may not perform the operations in the same (relative) time. So relying on simulators for speed tests in itself is a flawed premise.
Speed tests are notoriously tricky to get right, and if you mix in cryptography then it just got a whole lot trickier.