Shared UI vs Shared Logic Architectures

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:

User Interface

Business Logic

Data Access

API Communication

Storage

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.

Shared UI

Shared Business Logic

Shared Data Layer

        ↓

Android
iOS
Desktop
Web

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.

Shared Business Logic

Shared Validation

Shared Networking

Shared Data Access

        ↓

Native Android UI

Native Apple UI

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.

Same Building

Same Layout

Same Menu

Same Decor

Same Procedures

Customers receive an almost identical experience regardless of location.

Consistency is prioritised.

Shared Logic Architecture

Now imagine a franchise model.

Shared Recipes

Shared Ingredients

Shared Food Safety Rules

Shared Management Processes

However:

Different Buildings

Different Decor

Different Seating Layouts

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.