Prove iOS does not turn photos on their side #239

2026-09-08T21:47:32Z

paulhitt commented

2026-09-08 21:47:32 +00:00

(Migrated from gitlab.com)

A user reported a photo auto-rotating. The suspicion was this app's own
doing: every image sent is re-encoded to strip EXIF — right, because
that block carries the GPS coordinates the shot was taken at — and the
same block carries the Orientation tag. A phone camera rarely writes
upright pixels; it writes landscape pixels plus "turn this 90°". Strip
the tag without baking the rotation in and every portrait photo lands on
its side.

That is not what is happening here. Both re-encode paths draw through
UIKit, which applies imageOrientation, so the output is upright pixels
with no tag needed. The reporter has since confirmed iOS is fine.

Tests anyway, because the failure is invisible until somebody sends a
photo and only reproducible with a real camera file:

The fixture is built with ImageIO, not UIImage.jpegData(). That was
the first attempt and it made the suite vacuous — jpegData() BAKES the
rotation and writes Orientation = 1, so the bytes under test were
already upright and every assertion passed without exercising anything.
The tag has to be written deliberately. One test now asserts the fixture
itself carries Orientation = 6 over landscape pixels, so the suite fails
loudly if it ever stops testing what it claims to.

Also covers the mirror-image bug: an upright photo must not be rotated
BY the fix.

4 new tests; 764 XCTest + 65 Swift Testing green.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

A user reported a photo auto-rotating. The suspicion was this app's own doing: every image sent is re-encoded to strip EXIF — right, because that block carries the GPS coordinates the shot was taken at — and the same block carries the Orientation tag. A phone camera rarely writes upright pixels; it writes landscape pixels plus "turn this 90°". Strip the tag without baking the rotation in and every portrait photo lands on its side. That is not what is happening here. Both re-encode paths draw through UIKit, which applies imageOrientation, so the output is upright pixels with no tag needed. The reporter has since confirmed iOS is fine. Tests anyway, because the failure is invisible until somebody sends a photo and only reproducible with a real camera file: The fixture is built with ImageIO, not UIImage.jpegData(). That was the first attempt and it made the suite vacuous — jpegData() BAKES the rotation and writes Orientation = 1, so the bytes under test were already upright and every assertion passed without exercising anything. The tag has to be written deliberately. One test now asserts the fixture itself carries Orientation = 6 over landscape pixels, so the suite fails loudly if it ever stops testing what it claims to. Also covers the mirror-image bug: an upright photo must not be rotated BY the fix. 4 new tests; 764 XCTest + 65 Swift Testing green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

paulhitt commented

2026-09-08 21:47:32 +00:00

(Migrated from gitlab.com)

assigned to @paulhitt

paulhitt commented

2026-09-09 00:09:24 +00:00

(Migrated from gitlab.com)

mentioned in commit babdfc499b

mentioned in commit babdfc499b4e91975a8f2e5fd1597814b20a0488

paulhitt (Migrated from gitlab.com) merged commit babdfc499b into main

2026-09-09 00:09:24 +00:00

paulhitt commented

2026-09-09 18:59:54 +00:00

(Migrated from gitlab.com)

changed the description

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: extant2000/flamenet-messenger-ios#239