Insights28 January 2026Updated 25 October 20265 min read

Cross-Platform UI Frameworks: Keep the Data Contract Independent

A glowing tree with blue and yellow energy swirls around its roots, set against a futuristic dashboard interface with graphs and data panels.

A shared screen is not our acceptance test for shared data. When selecting a cross-platform UI framework for a logging application, we recommend starting with the record that must survive the application: what it means, who may change it and how another system will read it. Evaluate the interface against that contract, rather than treating matching screens as proof that the records agree.

For an inspection workflow, ask a concrete question. Can a record captured on a phone be reopened on another supported device, corrected by an authorised colleague and exported without changing its meaning? Use that journey to evaluate the framework and its storage integration. Treat visual consistency as a separate requirement.

Define the record before the form

Start with a written example of a complete inspection. Give each field a business definition, identify which values are required and distinguish an unanswered question from a negative answer. Agree whether a correction replaces a value or creates a new revision. These are proposed design decisions, not properties we would assume from a framework choice.

Consider a hypothetical form with an inspection result and a follow-up date. Decide whether an empty date means that no follow-up is required, that the inspector has not decided, or that the device lacks the necessary information. Require the interface and the receiving service to apply the same interpretation. Do not let separate teams choose different meanings for the same empty field.

Keep this contract outside the screen implementation. In chapter 3 of Continuous Architecture in Practice, Murat Erder, Pierre Pureur and Eoin Woods treat data representation as a software asset that needs deliberate management as it evolves. Our recommendation is to apply that discipline to the records exchanged by every supported client, including older versions.

Use a common format without assuming common meaning

JSON is a language-independent interchange format, but we would not use a successful JSON parse as the acceptance test for an inspection. Document the allowed fields, their meanings and the response to invalid input alongside the format. Specify what happens to a field that a receiving client does not recognise.

RFC 8259 also recommends unique names within an object. Make duplicate-field rejection an explicit test for your chosen implementation. Test the actual encoder and decoder used on each supported platform instead of assuming their behaviour from the file extension.

For dates, separate the instant of capture from a date chosen for a business purpose. RFC 3339 identifies unqualified local times as an interoperability problem. For capture timestamps, we recommend an agreed representation with an explicit UTC offset. For a follow-up date, decide whether a calendar date is the intended value and test that travelling between time zones does not change it.

Choose sample records that expose those decisions. Include missing optional values, non-English text and dates near a change of day. Ask each platform to write and read the same examples, then compare the business values rather than the displayed formatting.

Evaluate framework integrations through the data journey

For each framework candidate, build a small prototype of the same inspection journey. Include local persistence, attachment references and the handover to the receiving service. Ask the team to demonstrate what remains after closing and reopening the application. Record which parts of that behaviour are implemented by application code and which depend on a library or native integration.

Make storage decisions explicit. Define when the interface may say that a record is saved, when it may say that the record has reached the service, and how the user sees an unresolved correction. Require the prototype to demonstrate those states separately. Do not award a framework credit for an offline workflow that the team has only described.

Keep the comparison bounded. This exercise is about whether each candidate can preserve your record contract through the required journey. It is not a claim that one framework is universally better, or that a common interface automatically provides an audit trail. Put accessibility and device support in their own acceptance criteria rather than making data continuity stand in for every requirement.

Plan for old records and mixed application versions

Before adding a required field, decide how an existing record without that field should be read. Before changing the meaning of a status, decide how an older client should respond. Use the book's schema-evolution guidance as a reason to plan these changes explicitly, not as permission to assume compatibility.

Retain examples of older records as test fixtures. Ask the new application to read them, save a permitted correction and export the result. Also test the intended response when an older application encounters a newer record. Rejection with a clear explanation may be the right policy for a particular change. Silent reinterpretation should not be an accepted outcome.

For long-term access, request an export that a separate reader can interpret from the documented contract. Include attachment references and the information needed to understand revisions. Have someone outside the screen implementation check the sample. Make this a repeatable acceptance check when evaluating a framework upgrade or replacing a storage library.

Choose against evidence, not a demonstration screen

We recommend recording the framework decision with the demonstrated journey, unsupported cases and the owner of each data rule. If a candidate cannot complete a required handover, make the missing work visible before selecting it. Revisit that evidence when the contract or supported devices change.

For a smart logging system, this gives data continuity a testable meaning: the agreed record can be captured, reopened, changed and understood through the journeys you require. It avoids promising compliance from a UI choice. Start with one real workflow, write its acceptance criteria and use the result to make the next engineering decision.

Update, October 2026

For teams using coding agents to change these applications, we recommend providing the record contract and compatibility fixtures before implementation begins. Our engineering article on grounding packs describes giving a planner and reviewer the same evidence. Apply that approach to the data rules, while keeping the acceptance tests as the check on the resulting implementation.

Sources

Want this in your team?

Tell us what you're building and where you want to get to, and we'll think it through with you.

Let's have a chat Follow by RSS →

All insights →