Cross-platform development is an attractive starting point for a mobile product. One codebase can serve multiple platforms, shared business logic reduces duplication, and teams can deliver features without maintaining two completely separate applications.
Those advantages are real. But as FARY grows, we have to evaluate our mobile architecture against the actual demands of a ride-hailing platform, not just the speed at which we can build screens.
A ride-hailing application is not simply a collection of screens and API requests. It is a real-time system that depends on location, connectivity, background execution, maps, notifications, and reliable interaction with the operating system.
That is why we are moving toward native mobile development.
When the operating system becomes part of the product
In a typical business application, most of the important work happens while the user is looking at the screen. A ride-hailing app is different. Drivers may need to receive job offers, update their positions, and maintain an active session while the application is in the background or the screen is locked.
Android and iOS have different rules for background execution, location permissions, battery consumption, notification delivery, and lifecycle management. Cross-platform frameworks can access these capabilities, but complex features often depend on native APIs and platform-specific implementation details.
By investing directly in native development, we can build those critical paths around the behavior of each operating system instead of treating platform differences as implementation details hidden behind a shared abstraction.
Real-time location deserves first-class engineering
Location is one of the most important inputs in a ride-hailing system. It affects driver visibility, distance estimation, pickup coordination, route progress, and the passenger's understanding of where a driver is.
Reliable tracking is not about requesting GPS coordinates as frequently as possible. It requires choosing suitable update intervals, handling inaccurate measurements, filtering unnecessary movement, responding to lifecycle changes, and balancing freshness against battery consumption.
Native Android APIs such as Fused Location Provider and native iOS location services give us direct access to platform-specific controls. They allow us to design, test, and tune location behavior for the driver's actual working conditions.
The objective is not to claim that cross-platform frameworks cannot track location. They can. The objective is to reduce the complexity of critical platform integrations and give the team more direct control over their behavior.
Performance is more than screen-rendering speed
A fast application needs more than smooth animations. It must also respond predictably when processing location updates, rendering maps, receiving real-time events, handling navigation transitions, and recovering from connectivity problems.
Native development gives us direct access to each platform's UI toolkit, lifecycle, profiling tools, and performance diagnostics. This makes it easier to investigate platform-specific problems and optimize the parts of the application that matter most.
It does not automatically make every native application faster than every cross-platform application. Performance still depends on architecture, implementation, data processing, network behavior, and testing. Our reason for switching is to gain control over the areas where platform-specific behavior matters most.
Maps and navigation are not ordinary UI components
Maps are central to the FARY experience. They need to display driver positions, update routes, respond to camera movement, and remain usable while location data changes continuously.
Native map integrations can provide more direct control over platform SDK capabilities, rendering behavior, gestures, lifecycle handling, and location-related interactions. They also give us a clearer path to integrating platform-specific navigation and mapping features as our product evolves.
For a product that relies heavily on maps, reducing friction between the application architecture and the platform's mapping capabilities can be more valuable than sharing every line of UI code.
One product, two platform-specific experiences
Android and iOS share the same FARY service, but they do not have identical user expectations or operating-system behavior. Permissions, navigation patterns, accessibility, background restrictions, and system integrations differ.
Native development lets us respect those differences while keeping the product experience consistent. Shared API contracts, backend business rules, design specifications, and automated tests can preserve consistency without forcing both applications to use the same UI implementation.
The distinction is important: consistency comes from a well-defined product and architecture, not necessarily from a single mobile codebase.
The trade-off: more ownership, more responsibility
Moving to native development is not free. Android and iOS require separate implementations, separate platform-specific testing, and additional coordination when features change. Some functionality may need to be implemented twice, and the team must maintain expertise in both ecosystems.
We have to be deliberate about what we share and what we keep native. Backend contracts, API specifications, analytics definitions, business rules where appropriate, and product design standards can remain aligned. Platform-specific location tracking, lifecycle management, UI behavior, and system integrations can be implemented where they work best.
Native development is a strategic investment, not a shortcut. It makes sense only if the resulting control, reliability, and maintainability justify the additional engineering effort.
What success looks like for FARY
The migration should be measured by observable improvements rather than by the technology label alone. We need to evaluate location freshness, background tracking reliability, battery consumption, crash rates, application startup time, map responsiveness, and the stability of real-time job delivery.
We should also monitor development velocity, release quality, regression rates, and the cost of maintaining two applications. These measurements will help us understand whether the new architecture is delivering the benefits we expect.
Choosing the right architecture for the next stage
Cross-platform development helped make it possible to build and iterate quickly. As FARY's requirements become more demanding, we need an architecture that gives us greater control over the mobile operating systems our service depends on.
We are not moving to native because cross-platform development is inherently wrong. We are moving because real-time location, background execution, mapping, and platform-specific reliability have become central engineering concerns for our product.
At FARY, the mobile application is part of the operational infrastructure of a ride. The architecture must support drivers working in real conditions, passengers expecting timely information, and a backend that depends on accurate, consistent events.
The right technology is the one that helps us deliver that experience reliably, at scale, and over the long term.
