This is a test protocol, not a completed device review. We have no measured iPhone Duo battery, surface-temperature or gaming results to publish as of October 8, 2026. Apple's Vietnam product listing provides specifications; its video-playback claims do not predict gaming endurance.
Keep the modes comparable
Test folded and unfolded operation separately. Record game version, graphics settings, resolution policy, refresh-rate setting, brightness, network and audio route. Keep the case, power mode and ambient conditions fixed. A different screen area or render resolution can change the workload, so report what the app actually renders.
Use a repeatable route or replay with the same duration. If the game uses online opponents, record that uncertainty instead of treating different matches as identical workloads.
Build a test that can distinguish the display from the workload
A folding phone creates a useful experimental question: does changing the display mode change the same task’s energy use and delivered experience? Keep the task constant before answering it. Use the same game scene, playback material or browsing sequence, and record the display mode along with brightness, audio, network and application settings.
The comparison becomes misleading if opening the device also changes the game’s render resolution or quality preset without a note. That may be a real part of the owner’s experience, but it is a different question from comparing the screens under a matched workload. Run a matched test first, then a second session using the settings you would naturally choose for each mode.
Label those two sessions clearly. The matched session helps isolate a variable; the everyday session describes a practical routine. Neither should be presented as an all-purpose battery rating. Keep the starting charge range and ambient conditions comparable, and record deviations instead of quietly discarding an inconvenient run.
Record the session as a timeline, not a single impressive number
Write down the duration, task checkpoints and observed battery percentage at fixed intervals. Record interruptions such as incoming calls, downloads or a lost network connection. Those events may explain an outlier, but they should not disappear from the record. Repeating the session makes it easier to tell a persistent behaviour from a one-off disturbance.
For games, note whether performance changes after the device has been working for a while. A brief peak says little about a long session if frame delivery, quality or responsiveness later changes. Identify the source of every performance counter and avoid presenting a tool’s internal estimate as a calibrated laboratory measurement.
For temperature, use the device’s ordinary safety behaviour and manufacturer guidance. Do not defeat warnings or engineer an abnormal heat condition to obtain a striking result. If a session is stopped, record why and include it in the interpretation. A safely aborted test is evidence about that condition, not a reason to manufacture a completed run.
Measurement sheet
| Field | Record |
|---|---|
| Device and OS | Exact model, storage and software version |
| Environment | Ambient temperature and measurement location |
| Display mode | Folded/unfolded, brightness and refresh setting |
| Workload | Game version, route and graphics options |
| Battery | Start/end percentage and elapsed time |
| Frame pacing | Capture method, median and slow-frame distribution |
| Surface temperature | Instrument, fixed points and sampling times |
Do not call a battery-percentage drop a direct measurement of energy consumption. If the instrument reports electrical power, describe its connection and whether it changes the charging state.
Run sequence
Cool the device to the same starting condition. Launch the workload, separate warm-up from the timed interval, and repeat at least three times per mode. Alternate the order of modes to reduce a systematic advantage from testing one always first.
Record interruptions, background downloads and changing network conditions. Preserve every run. A failure or early stop is part of the result rather than a reason to silently discard the run.
Interpret cautiously
Report distributions, start conditions and measurement limitations before recommending a mode. Compare thermal behaviour only at the same surface points with the same instrument. Different chassis sizes can distribute heat differently, so one maximum surface reading cannot explain the internal cooling system.
Publish raw observations before deriving conclusions. Until hardware testing exists, the honest result is a plan and an empty results table. See the product overview for documented features.
Interpret a result without promising someone else the same endurance
A completed run applies to the conditions recorded with it. A brighter screen, weaker signal, background sync or a different application can change the owner’s outcome. Publish the fixture with the numbers so that a reader can identify which part resembles their own routine. The method is often more transferable than the headline duration.
Compare repeated runs using a simple summary and retain the raw observations. If the difference is inconsistent, say so. Separate visible defects from measured quantities: an uncomfortable grip is a useful personal observation, while battery percentage is a recorded counter, and energy consumption needs an appropriate instrument and definition.
At this article’s update date, AiFolder has not run this protocol on an iPhone Duo. Apple’s product imagery illustrates the device; the diagrams explain a proposed test. The article will need actual session records before it can become a hands-on battery or gaming review. That distinction protects the reader from treating a launch claim as an independent result.
