Browse Questions
- An Xcode MVVM Feature template generates three pre-wired files for SwiftUI screens (Model with explicit state enum, ViewModel with injectable service protocol, and View with StateObject…
- Encrypt mode makes the payload unreadable to anyone but the named peer and also proves its origin, while sign/verify mode leaves the payload in the clear and only proves who produced it and that…
- SwiftUI compares the new view tree with the previous one on every state change.
- Closure capture lists define explicit ownership rules for references captured inside a closure's body, breaking retain cycles by capturing instances as weak or unowned.
Answer: Encrypt mode makes the payload unreadable to anyone but the named peer and also proves its origin, while sign/verify mode leaves the payload in the clear and only proves who produced it and that it was not modified. Encrypt mode needs both key pairs; sign mode needs only the signer's private key.
Choose sign mode when something between the client and the recipient legitimately needs to read the body — an API gateway routing on a field, a log pipeline, a load balancer. Choose encrypt mode when nothing in the middle should see the contents.
Code Example:
// Encrypt: confidential + authentic. Requires the peer's public key.
let crypter = TSMessage(inEncryptModeWithPrivateKey: myPrivate, peerPublicKey: peerPublic)!
// Sign: authentic only. Body remains readable to any observer.
let signer = TSMessage(inSignVerifyModeWithPrivateKey: myPrivate, peerPublicKey: nil)!
// Verify on the other side with the signer's public key and no private key.
let verifier = TSMessage(inSignVerifyModeWithPrivateKey: nil, peerPublicKey: signerPublic)!
let original = try verifier.unwrapData(signedBlob)
Key Points:
- Signing is not encryption — a signed payload is fully readable in transit.
- Encrypt mode fails if the peer public key does not match the private key's algorithm.
- Verification failure throws; never treat a thrown error as "probably fine".