Dex: Created page with "'''Summary:''' Modern software is expected to run on an increasing number of platforms. Users may access the same application from desktop computers, laptops, tablets, mobile devices, kiosk systems, web browsers, and cloud-hosted environments. Historically, organisations developed separate applications for each platform. While this approach provides maximum control, it can significantly increase development and maintenance costs. This article explores the two primary a..."

2026-08-13T09:02:41Z

Created page with "'''Summary:''' Modern software is expected to run on an increasing number of platforms. Users may access the same application from desktop computers, laptops, tablets, mobile devices, kiosk systems, web browsers, and cloud-hosted environments. Historically, organisations developed separate applications for each platform. While this approach provides maximum control, it can significantly increase development and maintenance costs. This article explores the two primary a..."

New page

'''Summary:'''
Modern software is expected to run on an increasing number of platforms. Users may access the same application from desktop computers, laptops, tablets, mobile devices, kiosk systems, web browsers, and cloud-hosted environments.

Historically, organisations developed separate applications for each platform. While this approach provides maximum control, it can significantly increase development and maintenance costs.

This article explores the two primary approaches to multi-platform application design: platform-specific development and portable application design. It examines the strengths, weaknesses, and architectural considerations of each approach and provides guidance on choosing the most appropriate strategy.

== Context ==

The challenge of supporting multiple platforms is almost as old as software development itself.

An application may need to support:

* Windows
* macOS
* Linux
* Android
* iOS
* Browser-based environments
* Embedded systems
* Virtual desktop environments

The fundamental question becomes:

<blockquote>
Should the application target the platform directly, or should it target an abstraction that hides platform differences?
</blockquote>

How this question is answered shapes the entire architecture of the solution.

== Platform-Specific Design ==

Platform-specific design creates separate applications for each supported platform.

<pre>
Windows Application
│
▼
Windows

Android Application
│
▼
Android

iOS Application
│
▼
iOS
</pre>

Each application is developed using technologies native to that platform.

=== Examples ===

{| class="wikitable"
! Platform
! Typical Technologies
|-
| Windows
| Win32, WinForms, WPF, WinUI, .NET
|-
| Android
| Kotlin, Java
|-
| iOS
| Swift, Objective-C
|-
| macOS
| Swift, Cocoa
|-
| Linux
| GTK, Qt
|}

=== Advantages ===

* Maximum performance
* Deep platform integration
* Direct access to operating system features
* Native user experience
* Immediate access to new platform capabilities

=== Disadvantages ===

* Multiple codebases
* Increased development effort
* Increased maintenance costs
* Feature parity challenges
* Larger development teams

=== Typical Use Cases ===

Platform-specific design remains appropriate when:

* Maximum performance is essential
* Hardware integration is required
* Platform-specific user experiences are important
* Operating system features are heavily utilised

Examples include:

* Professional video editing software
* CAD applications
* Games
* Device drivers
* Operating system utilities

== Portable Application Design ==

Portable application design takes a different approach.

Instead of targeting individual operating systems, the application targets a shared runtime or abstraction layer.

<pre>
Application
│
▼
Runtime
│
▼
Platform
</pre>

The runtime is responsible for adapting platform-specific behaviour.

From the application's perspective:

<pre>
Application Logic
│
├── Windows
├── Android
├── iOS
├── macOS
└── Linux
</pre>

becomes:

<pre>
Application Logic
│
▼
Runtime
│
▼
Supported Platforms
</pre>

This significantly reduces duplicated development effort.

== The Role of the Runtime ==

A runtime acts as an intermediary between the application and the platform.

Responsibilities may include:

* File access
* Storage
* Networking
* Notifications
* Device integration
* Security
* Window management
* Rendering

Conceptually:

<pre>
Application
│
▼
Platform-Neutral APIs
│
▼
Runtime Environment
│
▼
Platform-Specific APIs
│
▼
Operating System
</pre>

The application primarily interacts with the runtime rather than the operating system directly.

== Common Portable Architectures ==

=== Browser-Based Applications ===

The browser is one of the most successful runtime environments ever created.

<pre>
Application
│
▼
Browser APIs
│
▼
Browser
│
▼
Operating System
</pre>

The browser abstracts significant platform differences.

As a result, a properly designed web application can operate on many operating systems with minimal modification.

=== Progressive Web Applications ===

Progressive Web Applications extend traditional web application capabilities.

Additional features include:

* Offline operation
* Background processing
* Local storage
* Notifications
* Installation support

A PWA remains fundamentally a web application but gains application-like behaviour.

=== Electron Applications ===

Electron uses a bundled browser runtime.

<pre>
Application
│
▼
Chromium
│
▼
Node.js
│
▼
Operating System
</pre>

Developers can create desktop applications using web technologies while maintaining a relatively portable codebase.

=== Cross Platform Frameworks ===

Modern frameworks provide platform abstraction while still producing native deployments.

Examples include:

* Flutter
* React Native
* Avalonia
* Uno Platform
* .NET MAUI

These frameworks seek to provide a balance between portability and native capability.

== Designing Around Abstractions ==

One of the most important architectural decisions is identifying which layer owns platform-specific behaviour.

=== Poor Separation ===

<pre>
Application
├── Windows Logic
├── Android Logic
├── iOS Logic
└── Linux Logic
</pre>

Over time, this approach often becomes difficult to maintain.

Every new feature may require changes across multiple sections of the codebase.

=== Better Separation ===

<pre>
Application
│
▼
Service Layer
│
▼
Platform Adapter
│
▼
Operating System
</pre>

The application remains largely platform agnostic while platform-specific concerns are isolated.

This approach improves:

* Maintainability
* Testability
* Portability
* Long-term scalability

== User Interface Considerations ==

The user interface is often the most visible challenge in multi-platform design.

Different platforms have different conventions.

=== Native Experience ===

Users generally expect applications to behave similarly to other applications on their chosen platform.

Examples include:

* Menu placement
* Navigation patterns
* Input behaviours
* Accessibility features

Ignoring platform conventions may create a poor user experience.

=== Consistent Experience ===

Some organisations prioritise consistency instead.

Examples include:

* Microsoft Office
* Adobe Creative Cloud
* Browser-based enterprise applications

Users encounter similar interfaces regardless of platform.

Both approaches are valid depending on business requirements.

== Offline-First Design ==

Modern multi-platform applications increasingly adopt an offline-first model.

Traditional architecture:

<pre>
Application
│
▼
Server
</pre>

Offline-first architecture:

<pre>
Application
│
▼
Local Data Store
│
▼
Synchronisation Layer
│
▼
Server
</pre>

The application interacts primarily with local data.

Synchronisation occurs separately.

Benefits include:

* Improved responsiveness
* Better reliability
* Reduced network dependency
* Enhanced mobile support

This design is increasingly common in mobile, cloud, and distributed applications.

== Web Runtime Environments ==

An emerging architectural pattern involves hosting applications within a dedicated runtime environment that implements or extends standard Web APIs.

Conceptually:

<pre>
Application
│
▼
Standard Web APIs
│
▼
Web Runtime Environment
│
▼
Operating System
</pre>

In this model:

* Applications target standard browser capabilities.
* Platform differences are handled by the runtime.
* Platform-specific implementations are hidden behind a consistent API surface.
* Applications remain largely unaware of the underlying operating system.

This approach builds upon concepts previously explored by browsers, HTAs, AIR, Electron, mobile runtimes, and progressive web technologies.

== Choosing The Right Approach ==

There is no universally correct solution.

The best architecture depends upon:

* Target audience
* Supported platforms
* Performance requirements
* Security requirements
* Offline requirements
* Team expertise
* Budget constraints
* Long-term maintenance goals

A useful guideline is:

<blockquote>
Target the highest level of abstraction that still allows the application to meet its requirements.
</blockquote>

This often produces the best balance between portability, flexibility, and maintainability.

== Common Misconceptions ==

=== Portable Means Less Powerful ===

Portable applications can often provide capabilities comparable to native applications.

The difference usually lies in the abstraction layer rather than the application's functionality.

=== One Codebase Solves Everything ===

A single codebase may reduce duplication, but architectural complexity still exists.

Platform differences do not disappear simply because they are hidden behind a framework.

=== Native Is Always Better ===

Native applications provide advantages in some scenarios.

However, portability, maintainability, deployment simplicity, and development speed may be more important than maximum performance.

== Key Takeaways ==

* Multi-platform application design requires balancing portability and platform integration.
* Platform-specific applications provide maximum control but increase complexity.
* Portable architectures reduce duplication through abstraction layers and runtimes.
* Browsers are among the most successful runtime environments ever developed.
* Modern frameworks continue the long-standing industry goal of write-once, run-anywhere software.
* Offline-first design is increasingly important in modern application architectures.
* Successful architectures separate application logic from platform-specific implementation details.
* The best solution is usually the simplest architecture that satisfies the application's requirements.

== Related Topics ==

* [[Applications Demystified]]
* [[The Evolution of Application Delivery]]
* [[Progressive Web Applications]]
* [[Cross Platform Development]]
* [[Runtime Environments]]
* [[Offline First Design]]
* [[Application Architecture]]
* [[Web Runtime Environments]]
* [[Software Portability]]

Application Design for Multiple Platforms - Revision history