Cross-platform
app development
in Waltham

A cross-platform framework promises one interface layer for two very different operating systems. Android and iOS never converged on how people expect an app to behave. Navigation patterns differ. Back gestures differ. Date pickers, alerts, and even the weight of a shadow read as foreign on the wrong platform. A shared codebase that ignores this produces an app that feels slightly wrong everywhere, without feeling wrong enough for anyone to say exactly why.

Flutter renders its own widgets rather than calling the platform toolkit directly, so it ships two widget sets: one that mimics Android conventions and one that mimics the iOS style. Choosing which set to use, screen by screen, is a design decision rather than a default. React Native leans the other way. Many of its components map to native views, so platform differences show up automatically, sometimes in places nobody planned for, like a switch control that looks nothing like the mockup.

A pragmatic team decides early which elements stay platform-specific and which stay shared. Typography, color, and iconography can be one visual system across both operating systems, since a consistent brand look is usually the point of building a single app in the first place. Interaction patterns are a different matter. A bottom tab bar that an Android user barely notices can feel out of place when it ignores how that platform normally surfaces navigation.

Small controls carry more weight than they seem to. A confirmation dialog on iOS usually places a cancel option on one side and a destructive action on the other; get the order backward and an experienced iOS user will tap the wrong button out of habit. Android date and time pickers look and behave differently from the iOS wheel picker, and swapping one for the other without checking a device screenshot is an easy way to ship a small paper cut nobody catches in a rushed review.

Gestures deserve their own pass. Swipe to go back is a system-level expectation on iOS. Disabling it inside a custom navigation stack, even by accident, reads as a bug rather than a design choice. Android carries its own back button and, on newer devices, its own gesture navigation, and a screen that traps a person with no visible way out gets uninstalled faster than one with a genuinely awkward layout.

Testing this properly means looking at the app on real devices running each platform default settings, not a simulator with those defaults changed to match a design file. A reviewer who only checks the Android build risks shipping an iOS release that technically works but never quite matches what an iOS user touches every day without thinking about it.

None of this argues against sharing code. Business logic, network calls, state management, and most of the screen layout can, and generally should, live in one place. The discipline lies in knowing which slice of the interface needs a platform-specific branch, and writing that branch on purpose instead of discovering it in a support ticket after launch.

Every cross-platform framework ships with a large plugin ecosystem. For common needs, camera access, maps, local notifications, someone has usually already published a package that wraps the native API. The gap appears with narrower hardware features: a specific Bluetooth Low Energy peripheral, a proprietary payment terminal, a scanner kit supplied by a hardware vendor. No public plugin covers it. The project cannot simply wait for one to appear, so the team has to build the bridge itself.

The fix is a native module: a small piece of Swift or Objective-C on one side, Kotlin or Java on the other, that talks to the hardware directly and exposes a narrow, well-defined interface back to the shared code. Flutter calls this a platform channel. React Native calls it a native module, or in newer versions a turbo module. The naming differs. The shape of the underlying work stays the same on both frameworks, and so does the discipline required to keep it maintainable.

Writing one well starts with resisting the urge to expose the entire native API. A payment terminal kit might offer forty methods. The app probably needs four. Wrapping only what gets used keeps the bridge small, makes it easier to test, and limits how much native code needs revisiting when the vendor ships a new version of its own kit.

Asynchronous behavior is where these bridges most often go wrong. A Bluetooth connection attempt on the native side does not return an answer immediately. It fires a callback, sometimes seconds later, sometimes never if the peripheral drifts out of range. Timing here is genuinely fragile. The shared code needs a clear way to represent that wait, plus a timeout, so a stalled native call does not leave the whole screen frozen with no way back to a working state.

Threading matters just as much. Native kits for scanners and payment hardware often run their own background threads and expect callbacks to return to the main thread before touching any interface element. Skipping that step produces crashes that are hard to reproduce. They only appear under specific timing, which makes them expensive to chase down once a build is already sitting with testers rather than sitting on a development machine.

Every native module also becomes a second, smaller codebase that someone has to maintain. That upkeep is easy to forget once the feature ships and works. Updating the shared framework to a new major version does not automatically update the native side. A module written a year earlier may need its bridging code adjusted by hand once the framework changes how it registers native code. Setting aside time for this upkeep, rather than treating the module as a one-time cost, keeps a single hardware integration from becoming the reason a whole app falls behind on framework updates.

Documentation inside the module matters more than in most parts of the app, because whoever touches it next may know the shared framework well and the native platform barely at all, or the reverse. A short note on why a particular thread hop or callback pattern exists saves real hours later. The vendor kit will change eventually, and the bridge will need at least a partial rewrite when it does.

Accessibility gets treated as a late addition on many projects, and a cross-platform app makes that habit more costly than usual. Flutter and React Native both abstract the interface layer, so accessibility metadata that a native app gets automatically from standard controls sometimes has to be added by hand, screen by screen, once a codebase is shared.

Flutter draws its own interface rather than using platform controls, which means a custom button or card carries no accessibility information unless a developer wraps it in a Semantics widget and states what it is. Skip that step and a screen reader user hears nothing useful, even though the screen looks complete and polished to a sighted reviewer running through the same flow.

React Native sits closer to native views, so some accessibility information does carry across automatically. It is not complete. An accessibilityRole prop set to button or link still needs to map correctly to how VoiceOver announces roles on iOS versus how TalkBack announces them on Android, and the two screen readers do not always agree on what a given role should sound like.

Reading order causes its own trouble. A layout built once in shared code can look correct visually. It can still produce a confusing path for VoiceOver swipe navigation on one platform, and a different, equally confusing path for TalkBack on the other. Visual order and reading order are not the same thing. A shared layout tree gives no assurance that the two line up on both operating systems.

Dynamic content adds a further wrinkle. When a screen updates without a page change, a loading spinner finishing, an error appearing, a badge count changing, each platform expects the update to be announced through its own mechanism. Android favors accessibility live regions. iOS expects a direct announcement call. A shared abstraction can offer one API for this, but the actual announcement still has to be checked on both platforms rather than assumed.

None of this shows up in an automated linting pass. Testing means turning on VoiceOver on an iOS device and TalkBack on an Android device and moving through the real app with the screen off, listening rather than looking. Teams that skip this step usually discover the gaps only when a real user, or an audit, finds them after launch.

Budgeting time for this work at the start, rather than at the end, changes how much it costs. Accessibility retrofitted after a shared codebase already has fifty screens means touching fifty screens one at a time, each with its own review. Built into a component library from the first screen, the same coverage becomes a property of the shared building blocks instead of a separate project layered on top of an app that already shipped.