Dex: Created page with "'''Summary:''' Cross-platform development is often discussed as though all frameworks and technologies pursue the same goal. In reality, different cross-platform architectures solve different problems. Some architectures seek to share both the user interface and business logic, while others focus on sharing only the application's underlying functionality whilst retaining native platform experiences. Understanding what is being shared is often more important than understa..."

2026-07-13T08:37:12Z

Created page with "'''Summary:''' Cross-platform development is often discussed as though all frameworks and technologies pursue the same goal. In reality, different cross-platform architectures solve different problems. Some architectures seek to share both the user interface and business logic, while others focus on sharing only the application's underlying functionality whilst retaining native platform experiences. Understanding what is being shared is often more important than understa..."

New page

'''Summary:'''
Cross-platform development is often discussed as though all frameworks and technologies pursue the same goal. In reality, different cross-platform architectures solve different problems. Some architectures seek to share both the user interface and business logic, while others focus on sharing only the application's underlying functionality whilst retaining native platform experiences. Understanding what is being shared is often more important than understanding which framework is being used.

== Context ==

As organisations sought to reduce the cost of maintaining separate Android and iOS applications, a variety of cross-platform technologies emerged.

From a distance, many of these solutions appear similar.

They promise:

* Reduced duplication
* Faster development
* Multi-platform support
* Improved maintainability

However, once examined closely, significant differences become apparent.

Some approaches attempt to share nearly everything.

Others deliberately preserve platform-specific user experiences whilst sharing only the application's logic.

These are fundamentally different architectural strategies.

The critical question is not:

''"What framework should we use?"''

Instead, it is:

''"What should be standardised, and what should remain platform-specific?"''

== What Gets Shared? ==

Every application consists of multiple layers.

For example:

<pre>
User Interface

Business Logic

Data Access

API Communication

Storage
</pre>

Cross-platform architectures differ primarily in which of these layers they attempt to reuse.

The decision affects:

* Development speed
* User experience
* Testing requirements
* Maintenance effort
* Long-term flexibility

== Shared UI Architectures ==

=== Definition ===

Shared UI architectures attempt to reuse both the application's visual interface and its underlying logic.

The same screens, controls, workflows, and business rules are presented across multiple platforms.

Typically, most of the application exists within a single codebase.

<pre>
Shared UI

Shared Business Logic

Shared Data Layer

↓

Android
iOS
Desktop
Web
</pre>

Examples include:

* Flutter
* React Native
* .NET MAUI
* Ionic
* Capacitor-based applications

=== Advantages ===

==== Maximum Code Reuse ====

Most application functionality is developed once.

This can significantly reduce:

* Development effort
* Testing effort
* Documentation effort
* Maintenance effort

==== Consistent User Experience ====

Users encounter similar behaviour regardless of platform.

Workflows remain predictable.

Features remain aligned.

This is particularly attractive for products requiring a highly consistent brand identity.

==== Faster Initial Development ====

New features can often be delivered to all supported platforms simultaneously.

This can be valuable when:

* Launching new products
* Developing MVPs
* Building startup applications
* Working with limited development resources

==== Simplified Team Structure ====

A single team can typically support multiple platforms.

Knowledge becomes concentrated rather than fragmented.

=== Disadvantages ===

==== Reduced Platform Individuality ====

Android and Apple users often expect different experiences.

A highly standardised interface may feel less natural on one or both platforms.

==== Additional Framework Dependency ====

The application becomes dependent upon an intermediate framework.

This introduces another component that must be:

* Maintained
* Updated
* Supported

==== Platform-Specific Workarounds ====

Not everything can be perfectly shared.

Applications frequently require:

* Native integrations
* Platform-specific fixes
* Device-specific adaptations

The promise of "write once, run anywhere" should be viewed as an aspiration rather than a guarantee.

== Shared Logic Architectures ==

=== Definition ===

Shared Logic architectures focus on sharing the behaviour of the application rather than its appearance.

Business rules, data models, networking code, validation, and application services are shared.

The user interface remains native to each platform.

<pre>
Shared Business Logic

Shared Validation

Shared Networking

Shared Data Access

↓

Native Android UI

Native Apple UI
</pre>

Examples include:

* Kotlin Multiplatform
* Certain Xamarin architectures
* Enterprise service-layer architectures
* Custom shared-library approaches

=== Advantages ===

==== Native User Experience ====

Each platform retains its own conventions.

Applications feel natural to their users.

Navigation, controls, and interactions align with platform standards.

==== Reduced Business Logic Duplication ====

Critical application behaviour is implemented once.

Examples include:

* Authentication
* Pricing rules
* Calculations
* Validation logic
* Security controls

This reduces the risk of inconsistent behaviour between platforms.

==== Easier Platform Evolution ====

Operating systems evolve independently.

Because user interfaces remain native, adapting to platform changes is often simpler.

==== Strong Long-Term Flexibility ====

The user interface can evolve without affecting shared business logic.

Similarly, business logic can evolve without redesigning the presentation layer.

=== Disadvantages ===

==== Dual User Interface Development ====

Android and Apple interfaces still require separate implementation.

Although duplication is reduced, it is not eliminated.

==== Increased Architectural Complexity ====

Shared Logic solutions frequently require more architectural planning.

Additional effort may be needed to:

* Define interfaces
* Manage dependencies
* Coordinate platform teams

==== Higher Initial Investment ====

The architecture often requires greater discipline and planning before development begins.

== A Physical Analogy ==

The difference between these approaches can be visualised using a restaurant franchise.

=== Shared UI Architecture ===

Imagine a chain restaurant where every branch is identical.

<pre>
Same Building

Same Layout

Same Menu

Same Decor

Same Procedures
</pre>

Customers receive an almost identical experience regardless of location.

Consistency is prioritised.

=== Shared Logic Architecture ===

Now imagine a franchise model.

<pre>
Shared Recipes

Shared Ingredients

Shared Food Safety Rules

Shared Management Processes
</pre>

However:

<pre>
Different Buildings

Different Decor

Different Seating Layouts
</pre>

Customers experience local variations whilst the underlying business processes remain consistent.

This is much closer to the philosophy of Shared Logic architectures.

== Architectural Comparison ==

=== Development Speed ===

Shared UI architectures typically provide the fastest initial development experience.

A single implementation can support multiple platforms simultaneously.

Shared Logic architectures usually require additional interface development for each supported platform.

=== Platform Consistency ===

Shared UI architectures excel at maintaining consistency.

Users encounter similar workflows regardless of device.

Shared Logic architectures allow experiences to diverge where appropriate.

=== User Experience ===

Shared UI prioritises consistency.

Shared Logic prioritises platform familiarity.

Neither objective is inherently superior.

The appropriate choice depends on project goals.

=== Maintenance ===

Shared UI architectures often reduce maintenance effort by centralising application behaviour.

Shared Logic architectures reduce duplication whilst preserving flexibility.

The optimal balance depends upon how frequently each layer changes.

=== Performance ===

Both approaches can achieve excellent results.

Performance is often determined more by implementation quality than architectural category.

== Understanding Business Requirements ==

Before selecting an architecture, organisations should identify what is genuinely unique.

=== Consumer Applications ===

Applications competing for user engagement may place significant value on platform-specific experiences.

Shared Logic architectures can be attractive where user experience differentiation matters.

=== Enterprise Applications ===

Many enterprise systems contain large amounts of shared functionality.

Examples include:

* Authentication
* Workflow processing
* Reporting
* Data access

Shared UI solutions may provide substantial efficiencies.

=== Internal Business Applications ===

Where users are trained and workflows are controlled, consistency often provides greater value than platform individuality.

=== Complex Multi-Platform Ecosystems ===

Applications targeting:

* Mobile
* Desktop
* Web

may benefit from extensive sharing where user requirements are broadly similar.

== Common Misconceptions ==

=== Shared UI Is Not Automatically Inferior ===

Some developers incorrectly assume shared interfaces are inherently less professional.

Many successful commercial applications use Shared UI architectures.

The architecture should be judged by results rather than ideology.

=== Shared Logic Is Not Purely Native ===

Although the presentation layer remains native, significant portions of the application remain shared.

It is best viewed as a hybrid approach rather than a fully native strategy.

=== More Sharing Is Not Always Better ===

Excessive standardisation can introduce complexity.

Sometimes duplication is cheaper than abstraction.

Good architects recognise the difference.

== Design and Architecture Considerations ==

When evaluating either approach, consideration should be given to:

* Long-term maintainability
* Team structure
* Platform roadmap requirements
* User experience expectations
* Hiring considerations
* Vendor lock-in
* Testing requirements

Technology selection should be guided by business objectives rather than industry trends.

== Practical Guidance ==

=== Shared UI Makes Sense When ===

* Consistency is important
* Development speed is critical
* Resources are limited
* Multiple platforms are required
* User experience differences are relatively minor

=== Shared Logic Makes Sense When ===

* Platform-specific experiences matter
* Business logic is highly complex
* Long-term maintainability is a priority
* Platform evolution is expected
* Native integration requirements are significant

=== Either Approach Can Succeed When ===

* Requirements are clearly understood
* The architecture is implemented well
* Teams possess appropriate skills
* Maintenance requirements are considered from the outset

== The Real Question ==

Many architecture discussions focus on selecting technologies.

Experienced architects often begin elsewhere.

They ask:

''"What part of the system changes least frequently?"''

The answer frequently determines what should be shared.

For some applications, the user interface remains relatively stable.

For others, the business rules represent the true long-term asset.

Identifying these characteristics early can significantly improve architectural decisions.

== Conclusion ==

Shared UI and Shared Logic architectures are not competing versions of the same idea.

They represent different philosophies regarding standardisation.

Shared UI architectures seek to standardise the entire application experience.

Shared Logic architectures seek to standardise application behaviour while respecting platform differences.

Neither approach is universally superior.

The most successful solutions emerge when architects understand what should remain consistent, what should remain flexible, and where the organisation derives the greatest long-term value.

Good architecture is rarely about maximising code reuse.

It is about sharing the parts of a system that provide the greatest benefit whilst allowing the rest of the system to evolve naturally.

Shared UI vs Shared Logic Architectures - Revision history