Adelante is a quotes app I built in Flutter. It has been on the App Store since 4 October 2026. Its home-screen widgets are not Flutter: on iOS they are WidgetKit extensions in Swift, and on Android they are app widgets in Kotlin. A widget has to change its quote on schedule while the app is closed, so the rule that decides which quote is showing at a given moment exists three times: once in Dart, once in Swift and once in Kotlin.
The three copies must agree. When the user opens the app, the Dart side works out which quote should be current and republishes the widget. If the native copy had reached a different answer, the widget visibly jumps to another quote. Nothing crashes, and no test turns red. It just looks wrong.
The project's guard for this was a set of 22 structural contract tests. Because the Dart test runner cannot compile Swift or Kotlin, those tests read the native source files as text and check that certain strings are present, such as currentPoolIndex or payload.interval > 0. All 22 pass on the shipping code.
This report asks a direct question: do the three copies actually compute the same thing? I answer it with differential testing [1]. I lifted each implementation into a runnable harness, fed all three the same generated inputs, and compared their answers instant by instant. The idea is old. Running independently written versions side by side is the core of N-version programming [2], and Knight and Leveson showed that such versions fail together more often than independence would predict [3]. Here the versions were not written independently. Each was written to mirror the others, which makes disagreement more surprising when it appears.
The answer is mostly yes, but not always. Across {n(TOT)} query instants in 29 IANA time zones, all three runtimes agreed on {pct('ALL|all3')} and the two native copies agreed with each other on {pct('ALL|swift=kotlin')}. The remaining disagreements trace back to eight distinct root causes. All eight are about calendar arithmetic: what "the same local time tomorrow" means when a clock change removes or repeats an hour. Date and time errors of this kind are a known, common class of bug [4]. None of the eight made any of the 22 contract tests fail.
McKeeman described differential testing as giving the same input to several comparable systems and treating any difference in output as a candidate bug [1]. Its strength is that it needs no specification of the correct answer. Its weakness is the mirror image: if every system makes the same mistake, the test is silent. Csmith is the best-known large-scale example. It generated random C programs and compared compilers, and it found hundreds of compiler bugs [5].
N-version programming uses the same comparison at run time to tolerate faults [2]. Knight and Leveson's experiment with 27 versions found that independently developed programs failed together more often than chance would predict [3]. The lesson I take from it is that shared difficulty produces shared mistakes. Programmers find the same inputs hard.
Adelante's situation is the reverse of an N-version system. The three copies are deliberately dependent: each comment says it "mirrors" the Dart function. Differential testing still applies, but it can only show where the copies disagree. It cannot prove that the point they agree on is the one the user wanted.
Metamorphic testing checks relations between the outputs for related inputs, for example "moving every instant by one rotation period advances the index by one" [6] [7]. Property-based testing, popularised by QuickCheck, generates many inputs and checks a stated property on each [8]. Both suit this problem. I chose plain differential testing because the three implementations already give an oracle for free. The vector generator borrows from property-based testing: it is seeded and deliberately biased towards edge cases.
The IANA time-zone database records each zone's rules and their history [9]. Two facts from it drive this study. First, local clock times can be skipped (a "gap", when clocks go forward) or repeated (an "overlap", when they go back). Second, zones disagree on where those changes fall. Most happen at 01:00 to 03:00, some at midnight, and Lord Howe Island moves by 30 minutes. Each language's calendar library has to choose what a skipped or repeated time means. Tiwari et al. studied 151 date and time bugs in Python projects and found time-zone mistakes to be the largest contributing factor, often caused by misunderstood library defaults [4]. My results are a cross-language version of the same pattern.
Fazzini and Orso's DiffDroid compares one Android app's behaviour across many platform versions and devices to find cross-platform inconsistencies [10]. My setting differs in two ways. The implementations are in different languages rather than one binary on different platforms, and the comparison is of a pure function rather than of user interfaces. The aim is the same: one app, one intended behaviour, several runtimes.
""") sec("rule", "3 The rotation rule and its three implementations", f"""A widget configuration has a pool of up to 96 quotes, chosen and ordered by the Dart app. The quote that is current at publication comes first. The user picks a cadence: manual, hourly, twice daily, daily or weekly. A daily cadence can also have a local clock time, such as 07:00. The rule answers one question: at instant t, which pool index is showing?
When the app publishes, widget_payload.dart writes a small record for the native side. For fixed intervals it writes an anchor epoch in whole seconds and the interval length in seconds. For a daily clock time it also writes the next 96 local change instants, computed in Dart with the device's time zone and converted to epoch seconds. The comment explains why: so the extensions "need no timezone database and never assume that a day lasts 24 hours". After those 96 instants, roughly three months, the native code has to extend the schedule itself. A flag, initialQuoteOnly, marks a quote the user chose by hand for Today. That quote holds only the first period and is not repeated when the pool wraps.
Dart, the app. When the app opens it does not call a single "index at time" function. It reconciles its saved queue in providers.dart. It counts elapsed changes with elapsedDailyChanges (daily clock time) or elapsedWidgetRefreshPeriods (fixed intervals) and shows queue[elapsed % n]. With a Today override, it handles the first period separately and then counts the rest from nextRefreshAt + interval.
Dart, currentPoolIndex. A pure function in widget_rotation.dart computes floor((t − anchor) / interval) mod n. Both native files say they mirror it. In the shipped code it is called only from tests, never from lib/. I include it as a fourth answer because it is the documented rule.
Swift. AdelantePayload.scheduledQuote counts the published instants up to t with prefix {{ $0 <= date }}. Past the last one, dailyStep adds whole calendar days using Calendar.current, startOfDay and date(bySettingHour:minute:second:of:). WidgetKit does not run this function continuously. adelanteTimeline precomputes up to 12 future entries, using Calendar.nextDate(…, matchingPolicy: .nextTime) once the published instants run out, and the system displays the latest entry whose date has passed.
Kotlin. scheduledIndex counts the published instants with count {{ it <= now }}. Past the last one it adds civil days and compares against dailyBoundary, which uses a lenient java.util.Calendar with the hour and minute fields set. An inexact AlarmManager window scheduled at nextChange() triggers each re-render.
Table 1 lists the concerns each copy has to get right. The three answers agree by construction only where the Dart-computed instants are used directly. Everywhere else, each language makes its own choices.
| Concern | Dart app | Swift widget | Kotlin widget |
|---|---|---|---|
| Fixed interval | milliseconds from nextRefreshAt | seconds (Double) from anchor | whole seconds from anchor |
| Daily, first 96 changes | own day count | count of published instants | count of published instants |
| Daily, after 96 changes | own day count | startOfDay + bySettingHour | UTC civil day + lenient Calendar |
| When the display updates | on open | 12-entry timeline, nextDate(.nextTime) | alarm at nextChange() |
| Today override | next + Duration(days: 1) | skip slot 0 after first step | skip slot 0 after first step |
I copied the relevant source files from Adelante's repository at commit af1aea2, the 1.0.0 (21) code, into a scratch directory. I recorded SHA-256 hashes and did not modify the repository. The rotation files are clean in that commit. Each harness contains the rotation functions copied character for character, and a script checks that every non-comment line of the copied Swift ranges appears in the harness. The changes I had to make are mechanical and listed in the artifact:
Timeline becomes a plain struct with the same entries and refresh date.SharedPreferences is replaced by a small interface backed by the configuration-catalog JSON. It reproduces the override in WidgetConfigurations.resolve, which is how the shipping widget reads its data.private modifier.The Dart answer for the app is the arithmetic extracted from providers.dart, not the provider itself, which depends on Flutter and Riverpod.
A seeded Python generator (seed 20261102) proposes inputs only. It never computes an answer. It covers 29 zones chosen for awkward rules:
For each zone the generator finds every UTC offset change from 2026 to 2030 by bisection. Around each change it builds five families of publications (Table 2):
Daily clock times include 00:00, 00:01, 00:30, 00:59, 01:00, 01:30, 02:00, 02:30, 03:00, 09:00, 23:00, 23:30 and 23:59. Pool sizes are 1, 2, 3, 5, 7, 24, 95 and 96, and 35% of publications carry a Today override. Query instants sit at each local change minute (both readings of a repeated time), one millisecond either side, around each offset change, and at random offsets.
| Family | Publications | Query instants |
|---|---|---|
| daily (inside the 96 published changes) | 2,756 | {n(Q['daily'])} |
| daily-tail (after the 96 changes) | 2,756 | {n(Q['daily-tail'])} |
| interval (hourly, 12 h, 24 h, weekly, manual) | 1,740 | {n(Q['interval'])} |
| long horizon | 232 | {n(Q['long'])} |
| leap day | 174 | {n(Q['leap'])} |
| Total | 7,658 | {n(TOT)} |
The queries are deliberately weighted towards boundaries. An agreement rate here is therefore a rate over hard cases, not over a typical day. A uniform sample of instants would show far higher agreement.
Figure 1 shows the pipeline. For each zone, the Dart harness runs with TZ set to that zone. It reproduces the publication: nextDailyChange or t0 + interval, the anchor and the 96 instants. It then records two answers per query: the app's reconciliation and currentPoolIndex. The Swift and Kotlin harnesses run in the same zone, read Dart's published payloads and record two answers each. The first is the instantaneous rule at t. The second is the displayed quote: the latest WidgetKit timeline entry, or the latest alarm-driven render, at or before t. Every harness checks that its runtime reports the requested zone.
The displayed answers rest on two idealisations. WidgetKit is assumed to request a new timeline exactly at its refresh date, and Android's ten-minute alarm window is assumed to fire at its start. Real devices can only be later, so these figures understate staleness.
There is no independent ground truth. I take the Dart app's reconciliation as the reference, because it is what the user sees after opening the app and what the widget gets republished to. Any native answer that differs from it is a visible jump. For every disagreement, a set of mechanical rules assigns a root-cause class from the answer pattern, the publication type and the local calendar facts at the query. Anything the rules cannot explain stays labelled as unexplained. I then reproduced one example of each class with a small probe of the library call involved.
I ran the real 22 contract tests with Flutter 3.44.1 on a scratch copy of the files they read. Then I built 14 single-line mutants of the native rotation code: 12 that change behaviour and 2 refactors that do not. Each mutant was applied identically to the contract-test copy and to the harness copy. A mutant counts as detected by the contract tests if any of the 22 fails. It counts as detected by the differential test if any answer changes in six zones (UTC, New York, London, Lord Howe, Santiago, Kuala Lumpur).
Dart 3.12.1 (Flutter 3.44.1); Swift 6.4 (swiftlang-6.4.0.34.1) with Xcode 27.1 on macOS 27.0.1, Apple M1 Pro, Foundation time-zone data 2026e; Kotlin 2.4.21 on OpenJDK 17.0.19, JVM tzdb 2026a; Python 3.14.2 for generation and analysis. Adelante's Android build uses the Kotlin Gradle plugin 2.3.20. Kotlin 2.4.21 was installed from Homebrew because no standalone compiler was present.
""") sec("results", "5 Results", f"""Across all {n(TOT)} queries, the three runtimes gave the same pool index for {n(ALL3)} ({pct('ALL|all3')}). Swift and Kotlin agreed with each other on {n(NAT)} ({pct('ALL|swift=kotlin')}). Table 3 breaks this down by vector family. Leap days caused no disagreement at all, and neither did zones without daylight saving apart from the sub-second effect in Section 5.2.
| Family | All three | App = Swift | App = Kotlin | Swift = Kotlin | currentPoolIndex = app |
|---|---|---|---|---|---|
| interval | {pct('interval|all3')} | {pct('interval|app=swift')} | {pct('interval|app=kotlin')} | {pct('interval|swift=kotlin')} | {pct('interval|cpi=app')} |
| daily | {pct('daily|all3')} | {pct('daily|app=swift')} | {pct('daily|app=kotlin')} | {pct('daily|swift=kotlin')} | {pct('daily|cpi=app')} |
| daily-tail | {pct('daily-tail|all3')} | {pct('daily-tail|app=swift')} | {pct('daily-tail|app=kotlin')} | {pct('daily-tail|swift=kotlin')} | {pct('daily-tail|cpi=app')} |
| long | {pct('long|all3')} | {pct('long|app=swift')} | {pct('long|app=kotlin')} | {pct('long|swift=kotlin')} | {pct('long|cpi=app')} |
| leap | {pct('leap|all3')} | {pct('leap|app=swift')} | {pct('leap|app=kotlin')} | {pct('leap|swift=kotlin')} | {pct('leap|cpi=app')} |
| All | {pct('ALL|all3')} | {pct('ALL|app=swift')} | {pct('ALL|app=kotlin')} | {pct('ALL|swift=kotlin')} | {pct('ALL|cpi=app')} |
The displayed quote matched the instantaneous rule on {pct('ALL|swiftShown=swift', 3)} of queries for Swift and {pct('ALL|kotlinShown=kotlin', 3)} for Kotlin. The rules correctly ignore leap days, 32-bit epoch limits and offsets such as +05:45 and +12:45. What they do not handle consistently is local clock times that are skipped or repeated.
Every disagreement fell into a named class. The classification left nothing unexplained. Figure 2 summarises the eight classes reachable with payloads the current app publishes.
Below, "tail" means a daily widget whose 96 published change instants have run out. That happens when the app has not been opened for about three months. It is plausible for people who use only the widget.
D1. Anchor truncated to whole seconds (Dart publisher; all 29 zones, {n(cs(K['D1']))} publications). The app's next change is selectedAt + interval, kept to the millisecond. The payload writes the anchor as millisecondsSinceEpoch ~/ 1000. Both native copies therefore change the quote up to 999 ms before the app would. This accounts for every disagreement in the interval family ({n(cq(K['D1']))} queries, because the generator deliberately probes the last second before each boundary). It is harmless in practice, but it is a real off-by-truncation.
D2. Today override adds 24 hours, not one day (Dart app; {cz(K['D2'])} zones, {cs(K['D2'])} publications). With a Today override, the app counts later periods from nextRefreshAt.add(refreshMode.interval), which is Duration(days: 1): exactly 24 hours. Across a clock change, that instant lands an hour away from the true next change, and elapsedDailyChanges miscounts. Example: New York, a change set for 03:00, override chosen on 10 March 2028. At 03:00 EDT on 12 March both widgets have moved to pool index 2. The app, if opened then, computes index 1 and republishes, so the widget steps back. Usually the window is one hour. When the shifted instant also crosses midnight, as for a 23:59 change in St John's on 11 March 2029 or a 00:01 change in Nuuk on 27 October 2029, the app's count stays one off for the rest of that publication. This happens only for widgets with a Today override, and only when a clock change falls within a day of the first scheduled change.
D3. A repeated minute resolved to the later hour (Kotlin tail; {cz(K['D3'])} zones, {cs(K['D3'])} publications). On a fall-back day, 01:30 happens twice. Dart and Foundation resolve 01:30 to the first occurrence (daylight time). A lenient java.util.Calendar with HOUR_OF_DAY and MINUTE set resolves it to the second (standard time). Kotlin's tail therefore changes the quote one hour late: in New York on 1 November 2026, from 01:30 EDT until 01:30 EST (Figure 3, top).
D4a. A skipped minute resolved to the end of the gap (Swift tail; {cz(K['D4a'])} zones, {cs(K['D4a'])} publications). On a spring-forward day, 02:30 does not exist. Dart's DateTime and Java's lenient calendar both move it forward by the gap, to 03:30. Foundation's date(bySettingHour: 2, minute: 30, …) returns 03:00, the first instant after the gap. Swift's tail changes the quote 30 minutes early in Los Angeles on 14 March 2027 (Figure 3, bottom). The early window equals how far into the gap the change time falls; a change set exactly at the start of a gap agrees.
D4b. Day count after a midnight change (Swift tail; {cz(K['D4b'])} zones, {cs(K['D4b'])} publications). This is the most consequential divergence. In zones where clocks go forward at midnight, such as Santiago, Havana, Cairo, Beirut and the Azores, the day of the change begins at 01:00. If the last published instant falls on such a day, Swift computes dateComponents([.day], from: startOfDay(last), to: startOfDay(date)). That spans 01:00 to 00:00 the next day, 23 hours, which Foundation counts as zero days. Swift then stays one quote behind for every following day until the app is reopened. In scenario s01648 (Santiago, change at 00:59, last published instant 6 September 2026), the lag was still present at the last query, nine days later. Kotlin builds its civil-day number from year, month and day, and so does not lag.
D5. Timeline entry dates and the step rule disagree (Swift display; {cz(K['D5'])} zones, {cs(K['D5'])} publications). Past the published instants, Swift's timeline places entries with nextDate(…, matchingPolicy: .nextTime), but evaluates each entry with dailyStep, which uses bySettingHour. When a change time is skipped and the two calls resolve it to different instants, an entry can be evaluated before the step it was meant to show. The widget then displays the previous quote until the next entry. In Nuuk, where clocks jumped from 23:00 on 28 March 2026 straight to 00:00 on 29 March, the displayed quote stayed one behind the rule from 00:00 to 22:59 on 29 March.
D6. The next alarm keeps a shifted wall-clock time (Kotlin display; {cz(K['D6'])} zones, {cs(K['D6'])} publications). After the gap day in D4a, Kotlin's nextChange takes the boundary it just used (03:30) and calls Calendar.add(DATE, 1). That keeps 03:30, not the configured 02:30. The next re-render is an hour late on the following day, although the rule itself is right.
D7. Dart's elapsed count disagrees with its own published list (Dart app; {cz(K['D7'])} zones, {cs(K['D7'])} publications). In Nuuk, a change set for 23:30 on the night clocks jump from 23:00 to 00:00 is moved by DateTime to 00:30 the next day. The published list therefore carries 00:30. elapsedDailyChanges counts by calendar date and already treats that day's change as passed at 00:00. For 30 minutes, the app is one quote ahead of both widgets and of the list it published itself.
One class falls outside the eight. In {cs(K['Apia'])} publications, Swift's day count also lagged across Samoa's skipped 30 December 2011. That is historical and no longer reachable.
currentPoolIndex, the function both native files claim to mirror, agreed with the app on only {pct('ALL|cpi=app')} of queries. For intervals it disagrees exactly where D1 does, because it receives the truncated anchor. For daily clock times it uses a fixed 24-hour interval, so it drifts by an hour across every clock change ({n(cs(K['Cd']))} publications). It is not called anywhere in lib/. The native comments point to a function that no longer describes the app's behaviour. One of the contract tests checks that the Kotlin file contains its name.
I also gave both native harnesses nine hand-built payloads that the current Dart publisher never produces, such as legacy or malformed data. Seven made Swift and Kotlin disagree (Table 4). Two legacy tier-filtering cases agreed at every width. None of these is a live bug. Each is a place where the two copies would split if the publisher changed.
| Payload | Swift | Kotlin | Disagree |
|---|---|---|---|
| Unsorted change instants | prefix stops at first later instant | count scans all | 6/13 |
| Anchor epoch 0 | rotates from 1970 | treats as unset, index 0 | 6/8 |
| Fractional interval (90.5 s) | Double | truncated to 90 s | 19/40 |
| Fractional change instants | Double | getLong truncates | 12/20 |
IDs café (NFC) and café (NFD) | equal under canonical equivalence | different code units | 2/6 |
| Interval stored as a string | ignored, manual | parsed | 4/6 |
| Anchor keys missing | falls back to ISO updated_at | index 0 | 4/6 |
The Unicode case deserves a note. Swift's String == uses canonical equivalence, so two IDs that differ only in normalisation compare equal. Swift's manual "Change quote" intent finds the current quote with firstIndex, so it would treat two such quotes as one. All 12,759 IDs in the bundled library are ASCII, so this cannot happen today. Quote length tiers are computed once in Dart and shipped as integers, which removes another possible Unicode divergence: UTF-16 length against grapheme count.
All 22 contract tests passed on the shipping code that contains D1 to D7. Six of the 22 touch the pool or its rotation. None refers to scheduleDates, dailyStep, scheduledIndex, dailyBoundary or nextChange, the functions where the native divergences live. So the answer to "would they have caught it?" is no for every divergence in Section 5.2.
The mutant study makes the comparison concrete (Figure 4). The contract tests detected {MBK} of {MB} behaviour-changing mutants. They did flag {MRK} of {MR} behaviour-preserving refactors. Renaming currentPoolIndex broke one test, and rewriting $0.tier <= maxTier as maxTier >= $0.tier broke another, although nothing a user sees changed. The differential test detected {MBD} of {MB} behaviour-changing mutants and flagged {MRD} of {MR} refactors.
The full run took {TIMING['cpu']['dart']} s of CPU in Dart, {TIMING['cpu']['swift']} s in Swift and {TIMING['cpu']['kotlin']} s on the JVM, summed over 29 processes per runtime. That includes process start-up and, for the native harnesses, simulating every timeline and alarm chain. In total that is about {TIMING['msPerQuery']} ms of CPU per query instant for all six answers. Wall-clock time is not meaningful: the machine was shared, with load averages between 68 and 112 throughout. Reproducing the run in a CI job is cheap. A trimmed vector set of a few thousand queries in six zones would take seconds.
""") sec("discussion", "6 Discussion", f"""The 22 contract tests were a reasonable answer to a real constraint: the Dart test runner cannot execute Swift or Kotlin. They prevent particular regressions they were written for, such as a removed accessibility label or a reintroduced shadow layer. For layout they are probably the right tool.
For calendar logic they are the wrong tool. A string test can only confirm that a line is present. It cannot say what the line computes. That limit cuts both ways. All 12 behaviour-changing mutants passed. Both harmless refactors failed, because the tests pin exact spellings. One of them pins the name of a function the app no longer uses. A string test gives assurance about the code's shape, not its behaviour.
The differential test removes the constraint instead of working around it. Swift and Kotlin both compile and run on a development Mac. The rotation functions are pure apart from Calendar.current and System.currentTimeMillis(), so they can run outside the app. The work was in extraction, not in the testing idea.
The Dart publisher already did the right thing for the first 96 changes. It computed change instants in Dart and shipped them as absolute times. In that region the native copies only count, and they almost always agree. Every native divergence appears where a copy computes local time itself: past the list, or when choosing when to wake up. Each language's calendar library answers "02:30 on a day without 02:30" and "01:30 on a day with two" differently, and each answer is a documented, defensible library behaviour. None of these is a bug in Dart, Foundation or Java. The bug is assuming that their answers match.
The two Dart-side divergences have the same shape. D2 uses a 24-hour Duration where the rest of the code uses calendar days. D7 counts calendar dates where the list it published counts instants.
I did not change Adelante. For the owner, in priority order:
The smallest fix that removes most of them is to make the native tail count published instants only. The app can publish further ahead, and the widget can say "open Adelante to refresh" once the list runs out. That is better than computing local time in two more languages.
""") sec("threats", "7 Threats to validity", f"""Harness fidelity (internal). The harnesses run copies, not the shipped binaries. Copied ranges are checked line by line, but the surrounding glue is mine. I could have changed how a value is decoded, for example how the catalog JSON reaches doublePref. I mirrored the production decoding paths (JSONSerialization on iOS, the catalog-backed SharedPreferences override on Android) and probed each divergence's library call on its own. The Dart app answer is extracted arithmetic, not the Riverpod provider. The app also rebuilds its queue when the UTC offset changes. I reasoned from the source, but did not execute, that this rebuild keeps the current quote.
Runtime differences (construct). Kotlin ran on a desktop JVM, not on Android's runtime. Android's java.util.Calendar descends from the same API, but its implementation and time-zone data differ. D3 and D6 should be confirmed on a device or emulator. Foundation on macOS is the same framework family as on iOS, but not the same build. The JVM's tzdb (2026a) is older than the macOS data (2026e). No divergence I found depends on rules that changed between those versions, but I did not check every zone.
Oracle choice. Treating the Dart app as the reference makes "divergence" mean "the widget will jump when the app opens". In D2 and D7 the two native copies are arguably closer to what the user intended than the app is. The classification reports who deviates, not who is right.
Idealised display timing. Real WidgetKit reloads and Android alarms are later and less regular than I assumed. Displayed-quote staleness is a lower bound.
Vector bias (external). Queries cluster at boundaries by design. Agreement rates describe hard cases. They are not the probability that a given user sees a wrong quote on a given day, which is far smaller.
""") sec("limitations", "8 Limitations", f"""This is one rule in one app by one developer. The eight root causes are all calendar arithmetic, because that is what this rule does. Logic involving hashing, sorting or floating point would need different vectors. I did not test the Watch app, which uses a separate Swift-only reading deck with its own SplitMix64 generator, the lock-screen surface offset, or the per-period manual selection. No devices, simulators or emulators were used. The mutant set is small and hand-written, so the detection counts illustrate the difference between the oracles rather than measure it. The study did not fix anything. Whether each divergence is worth fixing is a product decision for the owner.
""") sec("conclusion", "9 Conclusion", f"""Three copies of one small rule, each written to mirror the others, agreed on {pct('ALL|all3')} of deliberately hard instants. They did not agree on the rest, and the reasons were consistent: whenever a copy computed local time itself, its language's calendar library made a different choice about skipped and repeated hours. The project's 22 string-matching contract tests passed throughout and would have passed for any of the 12 behaviour-changing mutants. A differential harness of a few hundred lines per language caught every one. For shared logic across native targets, compute instants in one place, and test what the copies compute, not how they are written.
""") sec("artifact", "Artifact", f"""The artifact at /research/one-rule-three-runtimes/artifact/ contains:
scenarios.json);summary.json and mutants.json;Adelante's full source is not included. The copied functions are the only app code in the artifact.
""") # ---- citation numbering in order of first appearance ---- order = [] for s_ in sections: for rid in re.findall(r'href="#ref-([a-z0-9]+)"', s_["html"]): if rid not in order: order.append(rid) num = {rid: i + 1 for i, rid in enumerate(order)} for s_ in sections: s_["html"] = re.sub(r'\[\d+\]', lambda m: f'[{num[m.group(1)]}]', s_["html"]) refs = [] for rid in order: t, u = REFS[rid] refs.append({"id": rid, "text": t, **({"url": u} if u else {})}) assert set(order) == set(REFS), set(REFS) - set(order) words = sum(len(re.sub(r"<[^>]+>", " ", s_["html"]).split()) for s_ in sections) abstract = (f"Three copies of one daily-quote rotation rule in Adelante, written in Dart, Swift and Kotlin, agreed on {pct('ALL|all3')} of {n(TOT)} deliberately hard query instants, and the disagreements trace to eight distinct calendar-arithmetic divergences that none of the project's 22 string-matching contract tests detects. " "Adelante is a Flutter app on the App Store whose iOS and Android widgets reimplement the rotation natively so they can change quotes while the app is closed. " "I extracted each implementation into a runnable harness, generated 7,658 seeded widget publications in 29 IANA time zones, covering clock changes, midnight transitions, leap days and 13-year horizons, and compared the pool index each runtime shows at every query. " "All divergences arise where a copy computes local time itself: Java resolves a repeated hour to its later instance, Foundation resolves a skipped minute to the end of the gap and counts a 23-hour day as zero days, and the Dart app mixes 24-hour durations with calendar days. " f"In a mutant study the string-matching tests caught {MBK} of {MB} behaviour-changing mutants while the differential test caught {MBD} of {MB}. " "The report gives the root cause, trigger and duration of each divergence, and guidance for logic shared across native targets: publish instants, not rules, and test behaviour, not text.") paper = { "slug": "one-rule-three-runtimes", "title": "One Rule, Three Runtimes: Differential Testing of a Daily-Content Rotation Across Dart, Swift and Kotlin", "short": "One Rule, Three Runtimes", "authors": [{"name": "Yousof Selim", "affiliation": "Sunway University (Lancaster University dual degree), Malaysia", "email": "yousofselim2@gmail.com"}], "date": "2026-11-02", "version": "v1.0", "status": "Technical report", "area": "Software engineering · Testing · Cross-platform mobile", "keywords": ["differential testing", "cross-platform consistency", "time zones", "daylight saving time", "Flutter", "WidgetKit", "Android app widgets", "mutation analysis", "contract tests"], "projects": ["adelante"], "keyResult": {"value": "0%", "label": "of real and seeded rotation bugs caught by string-matching tests"}, "heroFigure": {"src": "/images/research/one-rule-three-runtimes/fig2-divergences.svg", "alt": "Horizontal bars for the eight divergences between Dart, Swift and Kotlin, showing how many of 29 time zones each affected, from all 29 for second-truncation down to 2 for a Dart gap case; none made a contract test fail."}, "pitch": "My app's quote rule runs in Dart, Swift and Kotlin. Testing them against each other found eight clock-change bugs the existing tests missed.", "findings": [ f"All three runtimes agreed on {pct('ALL|all3')} of {n(TOT)} deliberately hard moments across 29 time zones.", "The disagreements trace to 8 distinct bugs, all about clock changes: skipped or repeated hours and midnight transitions.", "If a widget's three-month schedule runs out on a midnight clock-change day, as in Santiago or Cairo, the iPhone widget stays 1 quote behind until the app is reopened.", f"The 22 existing string-matching tests caught {MBK} of {MB} deliberately broken versions of the rule; running the copies caught {MBD} of {MB}.", ], "abstractParts": [ {"label": "The problem", "text": "Adelante's widgets must change quotes while the app is closed, so the rule deciding which quote is showing exists three times: in Dart, Swift and Kotlin. The only guard was 22 tests that check the native source for certain strings."}, {"label": "What I did", "text": f"I ran verbatim copies of all three implementations side by side on {n(TOT)} generated moments in 29 time zones, chosen to stress clock changes, midnight transitions, leap days and long horizons, and compared their answers."}, {"label": "What I found", "text": f"They agreed on {pct('ALL|all3')}. The rest came from eight distinct calendar bugs, each a different library choice about skipped or repeated hours, and none made a string test fail. The string tests caught {MBK} of {MB} deliberately broken versions; running the code caught all {MBD}."}, {"label": "Why it matters", "text": "Shared logic across native targets drifts exactly where each language computes local time itself. Computing instants in one place and testing behaviour instead of text is cheap and catches what string checks cannot."}, ], "abstract": abstract, "contributions": [ "A cross-runtime differential harness that runs verbatim Dart, Swift and Kotlin copies of one shipping rule against 7,658 seeded publications in 29 time zones.", "Eight reproduced divergences with root cause, trigger and duration, plus seven latent ones in payloads the app does not yet publish.", f"A mutant comparison: string-matching contracts caught {MBK} of {MB} behaviour changes and flagged {MRK} of {MR} harmless refactors; the differential test caught {MBD} of {MB} and flagged {MRD}.", "Practical guidance for logic shared across native targets: publish instants, keep one notion of a day, and test behaviour rather than text.", ], "limitationsLine": "One rule in one app; Kotlin ran on a desktop JVM rather than Android, and display timing is idealised.", "aiStatement": "Yousof Selim designed and built Adelante and directed this study; much of the implementation and parts of this report were produced with AI coding assistants (Claude, Codex) under his direction and review; experiments are reproducible from the artifact.", "artifact": {"label": "Harnesses, golden vectors, raw per-runtime results and scripts", "href": "/research/one-rule-three-runtimes/artifact/"}, "sections": sections, "references": refs, "evidence": [], } paper["evidence"] = json.load(open(os.path.join(R, "evidence.json"))) json.dump(paper, open(OUTFILE, "w"), indent=1, ensure_ascii=False) print("words in sections:", words, "| abstract words:", len(abstract.split()), "| refs:", len(refs))