Application Streaming Explained: How On-Demand Delivery Works

Application streaming is one of the most under-appreciated delivery technologies in enterprise IT. It solves a specific, expensive problem — delivering large desktop applications to users quickly without full downloads — yet many IT teams do not understand how it actually works or when it is the right choice. This guide explains everything.

What Application Streaming Is

Application streaming is a technology where application code and assets are stored on a central server and delivered to user devices incrementally, in small blocks, as the application is being used. Instead of downloading a 2 GB installer and waiting for it to complete before the user can launch the application, the streaming client downloads only the first few blocks needed to start the application — typically a few megabytes. The application begins running while the remaining blocks are fetched in the background.

The key insight is that most applications do not use all of their code simultaneously. When a user opens Microsoft Word, they typically use a small subset of features in the first few minutes — typing, formatting, opening a document. The code for mail merge, advanced macros, or equation editing is not needed until the user actually triggers those features. Streaming exploits this pattern by deferring the download of rarely-used code blocks until they are needed.

The result is that users experience near-instant application launches even for large applications, while the network load is spread over time rather than concentrated in a single large download.

How Block-Level Streaming Works

The streaming process follows four stages:

1. Packaging: An administrator uses a sequencing tool to analyse the application and break it into blocks (also called pages or chunks). The sequencer captures all file system operations, registry changes, and DLL references the application makes, then packages them into a virtual application container. The container is split into blocks of typically 4-64 KB each.
2. Publication: The packaged application is uploaded to a streaming server or content store. The administrator configures which users or groups can access the application, and sets launch policies (e.g., pre-cache the full application overnight, or stream on demand).
3. Launch: The user clicks the application in their portal or Start menu. The streaming client on the device contacts the server, downloads the initial blocks (the blocks needed for the application to reach its main window), and begins execution.
4. Background fetch: While the user works, the streaming client downloads remaining blocks in the background. If the user triggers a feature whose blocks have not yet been downloaded, the client fetches them on demand — this may cause a brief pause (typically milliseconds to a few seconds) on first use of that feature.

The blocks are stored in a local cache on the device. On subsequent launches, the cached blocks are used instead of downloading from the server again. If the administrator publishes an updated version, the streaming client detects the new version and downloads only the changed blocks (incremental update).

Streaming vs Traditional Installation

Traditional installation copies the entire application to the device before the user can launch it. For a 2 GB application on a 100 Mbps connection, that is approximately 2.5 minutes of download time before the user can do any work. On a slower connection or shared network, it can be much longer.

Application streaming reduces this to seconds. The initial blocks (typically 5-20 MB) download in under 10 seconds on most connections. The user can begin working immediately while the rest downloads in the background.

• Updates: Traditional installation requires running the installer on every device. Streaming updates are applied centrally — the next time a user launches the application, they get the new version automatically.
• Rollbacks: With streaming, rolling back to a previous version is as simple as pointing the application publication to the old package. No reinstallation required.
• Administrative rights: Traditional installation typically requires local admin rights. Streaming does not — the application runs in the user context without modifying the OS.
• Conflict elimination: Streaming packages include virtualization that isolates the application from the OS and from other applications, preventing DLL conflicts and registry corruption.

Streaming vs Full Application Virtualization

Streaming is a delivery mechanism. Full application virtualization is an isolation mechanism. Many organisations confuse the two, but they address different problems:

• Scope: Streaming controls how the application reaches the device. Virtualization controls how the application runs on the device.
• Use case: Streaming excels for large applications where download time is a bottleneck. Virtualization excels when application conflicts or OS compatibility are the primary concern.
• Combination: Most modern platforms (Microsoft App-V, Citrix DaaS, Numecent Cloudpaging) combine both approaches. The application is packaged in a virtualized container (isolation) and delivered via streaming (incremental delivery). The two technologies are complementary.

For a deeper comparison of delivery methods, see our application streaming guide.

When Streaming Makes Sense

Application streaming is the right choice when:

• Applications are large: CAD tools, creative suites (Adobe, Autodesk), development environments, and engineering software are often 1-10+ GB. Streaming eliminates the long download wait.
• Bandwidth is limited: Branch offices, remote sites, and mobile workers often have constrained WAN bandwidth. Streaming spreads the load over time instead of requiring a large burst.
• Applications are infrequently used: If a user launches an application once a week, streaming avoids maintaining a full local installation for minimal usage.
• Updates are frequent: When applications are updated monthly or quarterly, streaming ensures users always get the latest version on next launch — no IT intervention required at the endpoint.
• Shared workstations: In healthcare, manufacturing, or education, shift workers share workstations. Streaming delivers the right applications to each user without maintaining multiple local installations.

When Streaming Does Not Make Sense

Streaming is not ideal when:

• Applications are small: If the application is under 100 MB, the overhead of sequencing and streaming infrastructure is not justified. Traditional installation is simpler.
• Offline work is constant: If users work offline regularly and the streaming solution does not support offline caching, streaming will cause more problems than it solves.
• The network is unreliable: Streaming depends on a stable network connection during the initial launch and for updates. Highly unreliable networks (satellite, intermittent cellular) may cause launch failures.
• Applications are deeply OS-integrated: Applications that require kernel-level drivers, system services, or deep OS hooks cannot be streamed because they modify the OS itself.

Platforms That Support Streaming

Several major platforms include streaming capabilities:

• Microsoft App-V: Microsoft\'s application virtualization platform includes streaming capabilities through its Streaming Server or Configuration Manager integration. App-V packages applications into virtual containers and supports on-demand streaming with background fetch.
• Citrix DaaS: Supports application streaming via HDX protocol, delivering apps to endpoints as needed. Combined with Citrix App Layering for packaging.
• Numecent Cloudpaging: Specialises in page-level streaming where only the specific code pages needed for execution are delivered. Minimal bandwidth footprint with strong offline support.
• VMware ThinApp: Primarily a packaging tool, but integrates with streaming servers for on-demand delivery of packaged applications.

Offline Caching and First-Launch Behaviour

The offline experience depends on how the streaming platform handles caching:

• Full cache: After the first launch, the entire application is cached locally. Subsequent launches (online or offline) use the local cache. This is the most common model for frequently-used applications.
• Block cache: Only the blocks that have been downloaded are cached. If the user has triggered 80% of the application features, 80% is cached. The remaining 20% requires a network connection on first use.
• No cache: Some configurations stream every time, with no local caching. This minimises storage but requires a constant network connection.

First-launch behaviour is critical for user experience. A well-configured streaming deployment pre-caches the most-used blocks overnight or during the user\'s first login, so the application launches instantly on subsequent uses. A poorly configured deployment may cause the user to experience pauses when triggering features whose blocks have not yet been downloaded.

Bandwidth and Network Considerations

Streaming reduces peak bandwidth demand but does not eliminate it. Key network considerations:

• Initial launch: Requires enough bandwidth to download the startup blocks within an acceptable time (typically under 10 seconds). A 5 MB startup block on a 10 Mbps connection takes 4 seconds.
• Background fetch: Occurs over minutes to hours, so it places minimal load on the network at any given moment.
• Concurrent launches: If 100 users launch the same application simultaneously, the streaming server must serve 100 x startup blocks concurrently. Capacity planning is essential.
• LAN vs WAN: Streaming from a local streaming server (branch office) is significantly faster than streaming over a WAN from a central data centre. Most deployments place streaming servers at each major site.

Getting Started with Application Streaming

If you are evaluating application streaming, follow these steps:

1. Identify candidate applications. Start with your largest, most frequently-updated applications. CAD tools, creative suites, and development environments are ideal first candidates.
2. Assess your infrastructure. You need a streaming server (or cloud content store), network connectivity to all user sites, and client software on each endpoint. Most streaming platforms run on standard Windows Server.
3. Pilot with a small group. Sequence 2-3 applications, deploy to a test group of 10-20 users, and measure launch times, network impact, and user satisfaction before rolling out broadly.
4. Plan for updates. Define a process for sequencing new application versions and publishing them to the streaming server. Most platforms support automated version rollover.
5. Monitor and optimise. Track cache hit rates, network utilisation, and user-reported issues. Adjust block sizes, caching policies, and server placement as needed.

For a comparison of streaming-capable platforms, see our application streaming guide or our complete software comparison.

Related Articles

• What Is Application Virtualization?
• Application Virtualization vs VDI
• Citrix Alternatives for Small Business