As with all things, the answer is "it depends".
If you're using a block mode with no padding (such as CTR or CTS) then you're probably fine. The ciphertext length is the plaintext length, your hashing time is a function of the known length, and you return "error" on tamper.
If you use a block mode WITH padding (CBC, ECB, etc) then you're not so fine. By using StE (or MtE) the recipient has to deal with the padding BEFORE knowing if it was a tampered message. So let's say that I'm a bad actor and I tamper with your message en route. I tamper wherever I need to tamper to mount a padding attack and observe results:
- If you reply "padding failure" then you are a true padding oracle, and I chortle and attack you very quickly.
- If you reply "error" sometimes in 'significantly' less time than others then you are checking the padding before starting the hash, and you have a noisy timing-based padding oracle. I smirk and attack you.
- If you reply "error" at almost always the same rate, but some more slowly than others, then I have hit the boundary condition between your plaintext interpreted padding length and the digest's padding length. You have a whispering oracle, and I grumble and attack you anyways. For good measure I fire up a botnet and DDoS you when I'm done, because you pointlessly annoyed me.
There's no situation where you win in online scenarios.
Note that this answer didn't care if you did asymmetric signature, MAC, or just a simple digest. You processed untrusted data and leaked info via a side (or direct) channel.
In offline scenarios there's not much room for oracle attacks, so you will reliably detect an error induced in the storage layer. Huzzah?
The right answer for padded block cipher modes is always EtM. That way every tamper is rejected at the same time interval, and now the attacker is left with brute forcing for success (which is fairly improbable if your MAC is in the 128+ bit space).
To relate to the Apple problem: An asymmetric signature is a valid message authentication code (some people reserve "MAC" for excluding asymmetric signatures). The problem, as also related in Do I need to use a MAC with asymmetric encryption?, is when you don't have an association of WHO is allowed to sign the particular message. Using a HMAC/etc only changes the equation by forcing the recipient to know a priori what key will be used. Binding the public key of the expected signer a priori solves the problem similarly.