Four decisions before sharing code across web and apps

Organize screens around the task

Start with what people need to accomplish: find an item, inspect it and make a change. Shared business rules can support different arrangements of that workflow. Sharing code does not require identical navigation or information density on every device.

For example, a course-management interface could place a list and its details side by side on desktop, while opening details on a separate mobile screen. Both use the same enrollment rules. This is a design example, not a client case study.

Check the complete task with touch, a pointer and a keyboard. A layout that fits the viewport can still be difficult to operate.

Define authoritative data and synchronization

Decide which system owns each value and when clients refresh it. Shared records such as orders and permissions need an authoritative server decision. Cached copies need a refresh rule, rather than an assumption that local data remains current.

• Shared records: decide when changes from another device become visible.
• Preferences: distinguish device settings from account-wide settings.
• Offline edits: define conflict handling and duplicate-submission behavior.

Consider two devices editing the same record. Accepting the latest write and asking someone to resolve a conflict produce different interfaces and tests. Make that decision before implementing synchronization.

Put platform capabilities behind a shared contract

Capabilities such as file selection, notification permission and payments can sit behind a shared interface. Each platform supplies the implementation. A payment interface can expose one operation while each platform supplies its implementation. The actual payment method depends on the product and distribution environment.

The contract should describe cancellation, network failures and unsupported capabilities as well as success. Otherwise every screen must invent its own interpretation of platform behavior.

Test shared logic separately from permission prompts and returning from external screens on real platforms. Adding a platform means adding both its implementation and its verification, even when the public interface stays the same.

Keep independently released versions compatible

A shared repository does not mean every user runs the same version. A web release may reach users while older mobile apps continue talking to the server. Define the compatibility window independently of the source-code structure.

When adding response fields, check older clients. When removing fields, plan the transition using the versions still in use. Rolling back an application does not automatically reverse a data migration.

• Record the source revision behind each preview build.
• Check new servers with older apps and new apps with the current server.
• Track rollout status and decide which functions can be stopped if a release fails.

Recording these boundaries makes later feature work easier to assess.