Food for Thought

For most software companies, the installer is the most overlooked part of the product.

It’s rarely celebrated. It doesn’t get roadmap debates. It’s not something customers ask for more of. And when it works, it’s invisible.

But here’s the thing: the installer is often the very first experience a customer has of your product. Before features. Before UX. Before value. It’s the moment where trust is either quietly established, or immediately put at risk.

And today, that trust depends more than ever on code signing.

At a basic level, code signing exists for two reasons: to prove that software hasn’t been tampered with, and to prove that it actually came from who it claims to come from. That hasn’t changed. What has changed is how strictly platforms now enforce those guarantees. Operating systems, browsers, and security frameworks have become far less forgiving. Unsigned or improperly signed software is no longer treated as a mild warning. In many cases, it’s blocked outright. Installers fail. Security prompts appear. Users hesitate, or walk away entirely. And when that happens, the damage isn’t just technical. It’s reputational. Because from a customer’s perspective, a broken or suspicious install doesn’t feel like a “signing configuration issue.” It feels like a company that can’t be trusted with their system.

When installs fail, users don’t debug — they judge

Most software teams are already signing their installers. On paper, they’re doing the right thing. But increasingly, that’s not enough.

Modern digital signing isn’t just about whether something is signed. It’s about how it’s signed, where keys are stored, how trust chains are validated, and what happens over time as certificates expire and standards evolve.

Miss one of those details and the failure mode is subtle but brutal:

• Security warnings that look alarming but vague
• Installers that appear to do nothing
• Corporate environments that silently block execution

None of this shows up clearly in a build pipeline. But all of it shows up in customer perception.

And once trust is lost at install time, it’s incredibly hard to win back.

Why Does This Matter Now?

Legacy approaches that once felt convenient, like storing signing keys in files on build servers, are increasingly discouraged or outright disallowed. New requirements emphasize stronger key protection, shorter certificate lifetimes, and more rigorous validation.

For software teams, this means digital signing can no longer be treated as a static configuration. It’s now an ongoing part of the software supply chain, one that directly affects customer experience, security posture, and brand credibility.

The teams that adapt successfully are the ones that recognize this early and design their release processes accordingly.

If you’d like to learn more about what’s changed in code signing, check out our free guide.

For software suppliers, installer architecture isn’t just a technical detail, it’s a strategic decision that influences customer experience, support costs, and brand perception. In 2026, 64‑bit has become the clear standard for performance, security, and compatibility with modern operating systems. Yet, pockets of 32‑bit usage persist in legacy environments and regulated industries where upgrades move slowly.

The real question isn’t “Which is better?”, that debate is settled. Instead, it’s “When does 32‑bit still matter, and how can suppliers manage the transition without frustrating customers?” This blog explores why 64‑bit is the new normal, why some customers still need 32‑bit, and how suppliers can strike the right balance between modernization and customer support.

Why is 64-bit the New Normal?

Modern computing has moved decisively towards 64‑bit architecture, and for good reason. Today’s operating systems and hardware are overwhelmingly 64‑bit, making it the default expectation for most customers. Shipping only 32‑bit installers can signal that your product is outdated, which impacts perception as much as performance.

Key Advantages of 64-bit installers

• Better Performance: 64‑bit applications can process larger data sets and run more efficiently on modern CPUs.
• Access to More Memory: Unlike 32‑bit systems, which are limited to 4GB of RAM, 64‑bit architecture supports significantly higher memory allocation, critical for resource-intensive applications.
• Enhanced Security: Many advanced security features, such as Kernel Patch Protection and Address Space Layout Randomisation (ASLR), are optimised for 64‑bit environments.
• Customer Expectations: For most users, 64‑bit is the standard. Offering only 32‑bit can create friction and raise questions about your product’s modernity.

Why Do Some Companies Still Need 32-bit?

For some customers, removing 32‑bit support too quickly will disrupt operations. Suppliers need to balance modernisation with these practical realities.

Key reasons customers still need 32-bit support:

• Legacy Software Compatibility: Many older applications and systems only exist in 32‑bit versions. For organisations running critical legacy software, such as industrial control systems or older ERP modules, 32‑bit support is non-negotiable.
• Regulated Environments: In industries like healthcare or manufacturing, strict compliance requirements often slow down upgrade cycles, leaving older hardware and operating systems in place.
• Global Markets: Emerging markets and regions with older infrastructure may still rely on 32‑bit systems, making universal 64‑bit adoption unrealistic in the short term.
• Virtual Machines and Embedded Systems: Some virtualized environments and embedded devices continue to operate on 32‑bit architecture for cost or compatibility reasons.

The Supplier’s Balancing Act

Maintaining two architectures can double your testing, documentation, and support costs. At the same time, removing 32‑bit too soon risks alienating customers who still depend on it.

Key considerations for suppliers:

• Cost vs Coverage: Every additional installer adds complexity, more QA cycles, more support tickets, and higher maintenance overhead.
• Customer Experience: Confusion over which installer to download can lead to frustration. Auto‑detect launchers or clear guidance on your download page can reduce errors.
• Brand Perception: Position 64‑bit as the default to signal modernity, while explaining why 32‑bit remains available for specific use cases.
• Data‑Driven Decisions: Use telemetry and support trends to determine where 32‑bit is still needed. If usage is minimal, plan a phased sunset strategy.

Best Practices for Suppliers:

• Lead with 64‑bit: Make 64‑bit the primary download option to align with modern expectations.
• Offer 32‑bit only where data shows real demand: Use telemetry and support trends to identify customers who truly need it.
• Simplify the choice: Consider a single “smart installer” that auto‑detects the right architecture, reducing confusion and support calls.
• Communicate early: If you plan to sunset 32‑bit, share timelines and migration guides well in advance.

How InstallShield Supports the Transition from 32-bit to 64-bit:

• 64‑bit Setup Launchers Across All Project Types: Whether you use Basic MSI, InstallScript, InstallScript MSI, MSIX, or Suite projects, InstallShield provides 64‑bit launchers to streamline migration.
• Custom Action Alternatives: If you need to migrate 64‑bit VB custom actions due to Microsoft’s deprecation, InstallShield offers PowerShell or InstallScript 64‑bit custom actions as alternatives.
• 64‑bit Digital Signing: Ensure compliance and security with full support for 64‑bit code signing.
• Visual Studio Integration: InstallShield integrates seamlessly with 64‑bit versions of Visual Studio, including Visual Studio 2022 and 2026, so your development workflow stays modern.

Looking Ahead

The industry trend is clear: 32‑bit support is shrinking fast. Operating systems, development tools, and security frameworks are all optimised for 64‑bit, and customers increasingly expect it as the default. Suppliers who plan ahead, by monitoring usage, guiding customers through migration, and leveraging tools like InstallShield, will reduce costs and improve satisfaction.

The future isn’t just about dropping 32‑bit; it’s about doing so strategically. Audit your installer download data, identify where 32‑bit is still critical, and set a phased sunset plan. Communicate early and often to avoid surprises and maintain trust.

Apple’s macOS security model has evolved significantly over the past few releases—and application notarization is now a mandatory requirement for most third‑party software distributed outside the Mac App Store.

For software publishers, this change impacts how installers are built, signed, tested, and delivered. In this post, we’ll explain:

• What macOS notarization is and why Apple requires it
• How notarization affects installers and update workflows
• How InstallAnywhere simplifies notarization for macOS installers

What Is Apple Notarization?

Notarization is an automated security check performed by Apple on macOS applications and installer packages. When you submit your software for notarization, Apple scans it for:

• Known malware
• Malicious behavior
• Suspicious code‑signing issues

Once approved, Apple issues a notarization ticket that confirms your software meets Apple’s security requirements.

When a notarized app is launched, macOS Gatekeeper verifies this ticket—either online or offline—before allowing the software to run without warnings.

Key point: Notarization does not replace code signing. Your application and installer must still be properly signed with a valid Apple Developer ID certificate.

Why Apple Requires Notarization

Apple introduced notarization to protect users from malware distributed outside the Mac App Store, while still allowing developers to distribute software independently.

Without notarization, users may see blocking dialogs such as:

“Apple cannot check this app for malicious software.”

Or the installer may fail to launch entirely on newer macOS versions.

From Apple’s perspective, notarization:

• Improves macOS ecosystem security
• Reduces malware propagation
• Preserves user trust in downloaded software

From a software publisher’s perspective, notarization is now non‑optional for professional macOS distribution.

What Needs to Be Notarized?

Depending on how you distribute your software, the following artifacts typically require notarization:

• .app bundles
• Installer packages (.pkg)
• Disk images (.dmg)
• Command‑line tools distributed to end users

If your installer contains embedded binaries, helper tools, launch agents, or frameworks, those components must also be correctly signed—or notarization will fail.

The macOS Notarization Workflow (High Level)

At a high level, the notarization process includes:

1. Code sign your application and installer with a Developer ID certificate
2. Submit the signed artifact to Apple’s notarization service
3. Wait for automated analysis by Apple
4. Staple the notarization ticket to the installer or app
5. Distribute the notarized installer to customers

While conceptually simple, real‑world installer projects often involve dozens—or hundreds—of files that must be handled correctly.

How InstallAnywhere Simplifies macOS Notarization

InstallAnywhere is designed to help software publishers navigate Apple’s notarization requirements without building custom scripts or fragile workflows.

With InstallAnywhere, you can:

Automate Code Signing

InstallAnywhere supports signing:

• Installer packages
• Embedded applications
• Helper tools and binaries

All from a centralized build configuration.

Streamline Notarization Submission

InstallAnywhere integrates notarization into the installer build process, reducing manual steps and errors.

Ensure Gatekeeper Compatibility

Installers built with InstallAnywhere are designed to pass Gatekeeper checks on modern macOS versions, minimizing end‑user friction.

Scale with CI/CD Pipelines

InstallAnywhere works seamlessly in automated build environments, helping teams notarize every macOS build consistently.

Best Practices for macOS Installer Notarization

To avoid last‑minute release delays, consider these best practices:

• Sign every executable file, not just the main app
• Use modern signing tools and avoid deprecated components
• Test installers on clean macOS systems with Gatekeeper enabled
• Integrate notarization early in your build pipeline
• Monitor Apple’s macOS security updates

Final Thoughts

Apple’s notarization requirements are here to stay—and they continue to evolve. For software publishers distributing outside the Mac App Store, notarization is a core release requirement, not an optional step.

By using a purpose‑built installer solution like InstallAnywhere, teams can:

• Reduce notarization failures
• Simplify macOS release processes
• Deliver a smoother experience for end users

Software licensing is rarely simple, especially for organisations that are moving their software to the cloud, with a mix of legacy systems, and growing security demands. In our recent webinar, we explored how two very different companies are tackling these challenges head-on by adopting InstallShield Cloud License Server (CLS) technology. Here’s what we learned.

Phased Cloud Adoption: The Multinational Power Company

For a large US-based power provider, licensing had become a minefield. Years of relying on outdated, unsupported models left them exposed to security risks and operational headaches. Deciding which products to upgrade and which to retire was never straightforward, especially with a portfolio spanning both old and new projects.

Maintaining physical licence servers was another pain point, costly, time-consuming, and increasingly out of step with their move towards cloud-based development. Rather than rushing into a wholesale migration, the company opted for a phased approach. CLS enabled them to gradually shift critical operations to the cloud, reduce reliance on physical infrastructure, and future-proof their processes.

As Rob Neff, Director of Global Inside Sales at Revenera, put it:

“There’s a sense of fear, uncertainty, and doubt that things could change next quarter, next year, or even three years from now. We want to be in a position to handle that. Ultimately, we helped them reduce both the cost and complexity of managing their systems, while also future-proofing their environment in case something changes down the road.”

The flexibility to switch cloud providers as business needs evolved was a significant advantage, allowing them to adapt without disruption.

Balancing Legacy and Innovation in the Building Industry

The second case study focused on a company in the building sector, responsible for hundreds of product lines and versions. Licensing here was often tracked manually, think spreadsheets and ad hoc processes, making errors and compliance issues all too common.

Balancing legacy and innovation was a constant challenge. Some products could be upgraded to newer releases, while others needed to remain in legacy mode due to regulatory requirements or resource constraints. Security and compliance were ever-present concerns, but upgrading everything at once simply wasn’t practical.

CLS provided a way to mix legacy and current solutions, enabling selective upgrades based on business priorities. Licence management became simpler and more secure, freeing up time for custom development and innovation.

Crispin Luxton, Co-Founder of TLUX, summed up the impact:

“Having access to both the latest version of InstallShield and those older heritage versions is important, because teams often don’t have the time or resources, from a QA or R&D perspective, to fully assess what an upgrade might involve. It’s not always as simple as just upgrading a project; there can be nuances and risks they’d rather avoid. So being able to make changes within the existing version gives them the flexibility to stay both cutting-edge and leading-edge.”

Lessons Learned

Both companies demonstrated that while CLS adoption can be complex, a flexible and gradual approach makes it manageable. The ability to adapt to changing business needs, support multiple cloud providers, and streamline licence management were key benefits.

The move to CLS isn’t about erasing challenges overnight, it’s about giving organisations the tools and flexibility to overcome them, modernise confidently, and focus on what matters most.

If you’re facing similar licensing challenges, consider how a phased, strategic approach, supported by flexible technology, can help your team move forward. And if you’d like to discuss your own situation, our team is always happy to chat.

Introduction: Why MSIX Still Matters

When Microsoft introduced MSIX at Build 2018, it marked a major shift in how Windows desktop applications are packaged, deployed, and serviced. Since then, MSIX has evolved from a promising new format into a strategic foundation for modern Windows application deployment—one that benefits software vendors, IT administrators, and end users alike.

The Problem: Why Traditional Installers Fell Short

For decades, Windows applications have relied on EXE, MSI, and App‑V–based deployments. While powerful, these technologies introduced persistent challenges that organizations still grapple with today:

1. Application Compatibility Challenges

Frequent Windows updates and platform changes often require extensive regression testing. Even with Windows 10’s incremental updates, compatibility issues remain a major operational burden.

2. Unreliable Installations and Uninstalls

Different installer technologies follow different rules. Over time, this inconsistency leads to:

• Failed installs
• Partial uninstalls
• Increased support tickets and vendor escalation

3. Complex Update Strategies

Every vendor handles updates differently—major upgrades, minor patches, side‑by‑side installs, or in‑place updates—forcing IT teams to manage fragmented deployment logic.

4. WinRot and DLL Hell

Legacy installers often leave behind files, registry entries, and shared DLLs. The result:

• Gradual OS performance degradation (WinRot)
• Broken applications due to overwritten dependencies (DLL Hell)

5. AppX Limitations

While AppX introduced modern concepts, it was constrained by limited APIs and did not fully support traditional desktop application scenarios.

Clearly, the Windows ecosystem needed a clean, consistent, and future‑ready packaging model.

The Solution: How MSIX Changes the Game

MSIX addresses these challenges by combining the best aspects of MSI, App‑V, and AppX, while eliminating their long‑standing drawbacks.

1. Containerized Applications by Design

MSIX installs applications into a lightweight container, isolating them from the operating system and from each other. This dramatically improves:

• Application compatibility
• System stability
• Predictability across devices

2. Declarative Installation Model

Instead of complex custom scripts, MSIX relies on a declarative manifest. This means:

• Fewer moving parts
• Consistent behavior across environments
• Easier validation and troubleshooting

3. OS‑Managed Lifecycle

With MSIX, Windows itself manages:

• Installation
• Uninstallation
• Updates
• Rollbacks

This ensures clean installs and clean removals—every time.

The Real Value of MSIX (for ISVs and IT Pros)

Beyond fixing legacy issues, MSIX delivers tangible business and engineering benefits:

• Improved Security: Tamper‑resistant packages, signed installers, and controlled runtime behavior
• Predictable Updates: Differential updates and seamless versioning
• Reduced Support Costs: Fewer install failures and environment‑specific issues
• Enterprise Readiness: Native integration with modern management tools like Intune and Configuration Manager

MSIX isn’t just a new package format—it’s a new operational model for Windows software delivery.

In this episode of Revenera’s TechTalk, Kendra Morton and Rob Neff discuss Revenera’s Cloud License Server (CLS) and its benefits, with a focus on InstallShield, Revenera’s software installation solution. They explain the two different license models for InstallShield and highlight the advantages of the concurrent license model. Rob then explains how the Cloud License Server provides a native DevOps extension for Microsoft Azure, allowing users to build projects in a DevOps pipeline. They discuss the target audience for the Cloud License Server option, which includes independent software vendors, companies with virtual development environments, and any software producer looking to leverage the cloud for cost savings and scalability.

Kendra Morton (00:00:06) – Hello, I’m Kendra Morton, product marketing manager at Revenera. Welcome to an episode of Revenera’ Tech Talk, where we discuss all things related to software installation. Today our topic is Revenera’s Cloud License Server or CLS. We’ll tell you a little bit about our InstallShield solution and the differences between our license types with a focus on CLS. What is it? What are the benefits to users? Those kinds of things. Joining me for today’s discussion is Rob Neff. Rob is the director of Inside Sales at Revenera with a focus on software installation solutions. Rob, thank you so much for taking the time to discuss with us today.

Rob Neff (00:00:45) – Yeah, happy to do so. Thank you, Kendra.

Kendra Morton (00:00:46) – Yeah, absolutely. So, Rob, before we talk about our cloud license server, I think we have to first tell our listeners what InstallShield is, so they have a reference for when we get into the details. So can you maybe provide a quick overview of InstallShield?

Rob Neff (00:01:05) – Yeah, absolutely. So InstallShield is primarily used for installing software to Microsoft Windows desktop and server platforms, but it also can support a variety of handheld and mobile devices.

Kendra Morton (00:01:17) – Okay. Very good. So. Next then, how is it licensed? How do we license our InstallShield solution?

Rob Neff (00:01:25) – Great question. We have two different license models. One is the very familiar and traditional node lock model, your single user single machine kind of situation. And then the other model is a much more flexible model, which is called a concurrent license model. Other organizations may refer to this as a floating or site license type model.

Kendra Morton (00:01:47) – Okay. So, when it comes to Revenera’s cloud license server, right? What are the benefits of that? What are the benefits from using CLS, for example?

Rob Neff (00:02:01) – Absolutely. Let me take a quick step back and a little further detail on the concurrent license. Really, what it does is it allows the sharing of InstallShield licenses between multiple users. And this provides a lot of additional flexibility and cost efficiency, but it also supports an unlimited total user pool. So, the only limit is determined by each customer and their unique environment and the needs they have.

So, maybe you have a need for a five-user concurrent license. Another company may need 25. It’s very customized and individualized, but we also offer two different versions. One is a local license server, but the other is this new product we’ve created, which is a cloud license server. And what this does is provides a Native DevOps extension for Microsoft Azure so that you can build your projects in a DevOps pipeline.

Kendra Morton (00:02:55) – Okay, very good. And I think that’s why it’s very important to understand what the difference between those two licenses is relative to InstallShield. So then, you know, for our users out there. Either existing customers or potential new InstallShield customers, right? Who benefits from using the cloud license server?

Rob Neff (00:03:21) – That’s a great question. Such a wide variety. Typically, we see it’s independent software vendors that are creating software applications. It could also be, you know, companies that have a virtual development environment, whether that be a static or a dynamic team or really any software producer that’s looking to monetize their solutions and offering more flexible models to their customers.

Currently, though, we’re seeing a lot of customers moving to the cloud. What does that mean? Mostly in the InstallShield world, it’s leveraging DevOps in the cloud with either Azure, AWS or even Google’s solution. So, if you’re moving a data center or if you’re just simply trying to save on hardware costs by leveraging virtual machines, those are typically some of the key takeaways for this license model.

Kendra Morton (00:04:14) – Very good. So, is there a use case or maybe is there anyone who’s not a good candidate for CLS to your thinking?

Rob Neff (00:04:24) – Yeah. I mean, so right off the bat, if you aren’t really doing some advanced installation development where you need to be able to do builds, maybe multiple builds for multiple products at the same time, you’re likely not going to find a value in the cloud license server if you’re not going to leverage the Microsoft hosted build agents and would be leveraging private agents than our node lock model does provide that base level support.

Kendra Morton (00:04:53) – Rob, what about total cost of ownership when it comes to the development environment? Who bears the brunt of that?

Rob Neff (00:05:02) – So with the cloud license server Revenera is going to go ahead and host the license server itself. So, any of the costs associated with that, along with the maintenance and ensuring that we’ve always got the most current version and security concerns are addressed. We take all of that on our shoulders. Another thing to bear in mind is with a cloud license server, you can reduce the costs associated to physical hardware, and some of these development machines can be pretty expensive, whether that’s a full-time desktop or even a full-blown server. So, leveraging the virtual technologies available in the in the market allow you to not have to have maintenance on physical machines and maintaining those to make sure they’re always current and up to date. Spinning up a VM on demand doing the needful, blowing away that image, makes things much more efficient and effective when it comes to creating the installers.

Kendra Morton (00:05:57) – So that’s really another huge benefit, right?

Rob Neff (00:06:00) – Yeah, absolutely. A lot of companies are being tasked with tightening their budgets or controlling their costs. And this is just one quick and easy way to get a handle on that.

Kendra Morton (00:06:13) – Again. So relative to using InstallShield in our cloud license server, do you think there are some very basic key takeaways that our audience that’s listening here today needs to know, needs to understand?

Rob Neff (00:06:30) – Yeah. I would say the biggest is the, the, the change from a single named user like my full-time job and responsibility is to create installation packages. Those days have kind of gone away and we’re seeing a lot more Scrum teams or organizations that are looking to leverage agile development. So, with a concurrent license that really provides you with that ultimate flexibility on the number of users that you have that can access the InstallShield license or building the projects themselves at the same time. Another good, good, you know, a takeaway would be is if you’re starting to think about moving to the cloud or trying to figure out and planning that transition. The good news is that InstallShield has a solution for you. Once you make that transition or make that move. Whether you want to take it one step at a time and leverage private agents that you’re hosting, or if you’re ready to go full, you know, all in on the deep end with a Microsoft hosted solution their build agents, then we can cover you. Whether it’s from soup to nuts. We got that covered.

Kendra Morton (00:07:34) – That’s fantastic. Rob, thank you. Think there’s probably going to be more to talk about and I hope you and I get a chance to do that again real soon. So, thank you for joining me today.

Rob Neff (00:07:43) – No, absolutely. I look forward to that and appreciate you taking the time.

Kendra Morton (00:07:46) – Yeah, Thank you. So, to our audience, we look forward to catching you on an upcoming episode of TechTalk. If you’re looking for more information on our suite of software installation solutions or more about cloud license server, check out revenera.com/install and we hope you have a great day.

Distributing software shouldn’t be harder than building it. Yet for many Windows applications, the last mile, getting users to install quickly and safely, is still a source of friction.

Microsoft has quietly made this experience far more seamless with the ms-appinstaller protocol activation scheme, enabling users to install MSIX applications directly from the web with a single click. No manual downloads. No confusing installer steps. Just click and install.

Let’s look at what this scheme enables, why it matters, and how InstallShield makes it easy to take advantage of it.

What Is the ms-appinstaller Scheme?

The ms-appinstaller scheme is a Microsoft-supported protocol that allows Windows to invoke App Installer directly from a web link. When a user clicks an ms-appinstaller: URL:

• Windows launches the built-in App Installer
• The MSIX package is streamed directly from the web
• The app is installed securely without requiring users to first download an installer file

This approach dramatically reduces user friction and aligns perfectly with modern expectations around web-first software distribution.

Why This Matters for Software Teams

From a product and engineering standpoint, this model delivers several tangible benefits:

• Faster time-to-value for users: Users install your application in one click, straight from your website or documentation.
• Improved security and trust: MSIX enforces signing, identity, and isolation, reducing the risks commonly associated with traditional installers.
• Consistent installation experience: App Installer provides a standardized UI, ensuring predictable behavior across Windows environments.
• Ideal for trials, utilities, and internal tools: Perfect for tools where you want users to “try it now” without friction.

Hosting Requirements (Made Simple)

To enable ms-appinstaller, the hosting server must support a few specific requirements (such as correct MIME types). Rather than configuring a custom server, many teams choose GitHub Pages, where these requirements are already handled out of the box.

This makes it extremely easy to prototype or even productionize an “install from web” experience.

A Simple Example: Installing from a Web Page

At the heart of this experience is a simple hyperlink:

<a href=”ms-appinstaller:?source=https://example.com/MyApp.msix”>

Install My Application

</a>

When users click this link, Windows takes over and handles the rest. That’s the “magic” of the ms-appinstaller scheme.

Where InstallShield Fits In

This is where InstallShield adds significant value.

InstallShield enables you to:

• Create native MSIX packages with full control over identity, signing, and upgrades
• Convert existing MSI installers to MSIX without rewriting your installer logic
• Digitally sign packages using enterprise-grade certificates
• Maintain clean upgrades and uninstalls, even when distributing via the web

In short, InstallShield lets you focus on how users experience your product, not on wrestling with packaging complexity.

The MSIX package used in our example is built and signed using InstallShield—demonstrating that enterprise-grade tooling and modern distribution models work seamlessly together.

Is It Safe?

Yes. MSIX packages installed via App Installer must be signed, and Windows clearly displays publisher identity before installation. This ensures transparency and builds user trust—especially important when installing directly from the web.

The Bigger Picture: Modern Windows App Distribution

The ms-appinstaller scheme is more than a neat trick—it’s part of a broader shift:

• From heavyweight installers → streamlined, web-first installs
• From manual setup steps → one-click experiences
• From legacy packaging → modern MSIX standards

With InstallShield, you don’t have to choose between enterprise robustness and modern delivery. You get both.

Try It Yourself

If you’re exploring MSIX or looking to modernize your Windows installation strategy, InstallShield gives you the fastest path from build to browser-based install.

Build once. Distribute everywhere. Install effortlessly.

We are delighted to share that our Software Installation solutions have once again been recognized by ComponentSource with the following prestigious awards:

• Top 25 Bestselling Publisher Award 2025 – Revenera
• Top 50 Bestselling Product Award 2025 – InstallShield Premier
• Top 50 Bestselling Product Award 2025 – InstallShield Professional

These esteemed awards highlight highlight the exceptional work that has gone into Revenera’s Software Installation solutions over the past year. We are incredibly proud of this recognition and honored to be acknowledged by ComponentSource.

ComponentSource is the world’s largest marketplace and community for reusable software components and development tools, with over 1.3 million licenses sold to more than 150,000 organizations in 180 countries. The Top 100 Bestselling Publishers and Products Awards are based on the total sales dollar value from customer orders placed during 2024, making this recognition a true reflection of market impact and customer trust.

Our continued investment in InstallShield’s capabilities has helped us stay at the forefront of the installer technology landscape. Some of the recent updates that contributed to this recognition include:

• Support for Azure Key Vault Signing using Custom Signing: Enhancing security and flexibility in the code-signing process for enterprise environments.
• ARM Support for InstallScript Setups on Windows 11: Expanding platform compatibility to meet the evolving needs of modern devices.
• Install Windows Package Manager Apps from Suite – Enabling developers to configure their suite to install apps from Windows Package Manager (WPM)

These innovations are just a few examples of how we continue to adapt to customer needs, industry changes, and modern application deployment practices.

We extend our heartfelt thanks to our customers and partners for your continued support. Your trust, feedback, and collaboration have been central to our success and evolution. Thank you for being a crucial part of our success. We look forward to continued excellence in the years to come.

Here’s a little more about our solutions. We encourage you to learn more and contact us if you have a question about our InstallShield or InstallAnywhere solutions.

InstallShield

InstallShield is the industry standard for developers creating installers for Windows desktops, servers, virtual and cloud platforms. Using Revenera’s Cloud License Server (CLS), you can now configure InstallShield to your CLS and build without any friction in cloud environments. You no longer need to configure a license server and upgrade for every release.

Key product features include:

• Support for MSIX
• Seamlessly build on cloud platforms using Cloud License Server

• Simplified builds within Docker
• Integration with Visual Studio
• And more

InstallAnywhere

InstallAnywhere is the leading multi-platform solution for developers creating installers for physical, virtual and cloud environments. More developers choose InstallAnywhere to build reliable and consistent installations because it offers an ideal combination of ease-of-use and powerful functionality.

Key product features include:

• Build installers that run seamlessly in the latest macOS versions
• Creates Java™-based installations for multiplatform applications, including Windows® 10/11
• Manages rules and dependencies. Automates processes
• Installs dependencies from Linux® package managers
• And more

While MSIX provides a modern, secure packaging model for Windows applications, compatibility with existing Win32 apps is a common concern. Many of these applications weren’t designed for containerized execution. The Package Support Framework (PSF) bridges this gap, enabling Win32 apps to run successfully within an MSIX package.

Running Win32 Apps

MSIX enforces a more isolated and predictable runtime. That delivers cleaner installs, safer upgrades, and better manageability — but it also restricts behaviors common to legacy installers and apps. Typical constraints include:

• Writes to the installation directory or current working directory are blocked or redirected.
• Hard-coded paths, first-run installer actions, and helper processes that rely on system-wide state can fail at runtime.

From an IT perspective that can look like a showstopper… until you apply the right compatibility layer.

What Package Support Framework (PSF) is, and How it Helps

The Package Support Framework (PSF) is an open-source toolkit from Microsoft that makes many Win32 apps work correctly inside MSIX without changing the app binary. PSF is built on Microsoft Detours technology and works by intercepting specific API calls at runtime and routing them to MSIX-friendly locations or behaviors.

How PSF Works

• MSIX replaces the app’s original EXE with the PSF Launcher.
• The Launcher reads a package configuration file (config.json) that lists one or more “fixups.”
• Each fixup is a small shim that intercepts targeted API calls (file I/O, environment lookups, process launches) and applies a runtime redirect or modification.
• The result: the app runs unchanged, but its read/write operations and environment are routed to locations compatible with MSIX.

For more detailed documentation on how PSF works, you refer to Microsoft’s documentation here.

Common Fixup Scenarios

• File redirection: redirect writes from Program Files to a per-user or package-local folder.
• Path remapping: rewrite hard-coded file paths so the app finds its resources.
• Process or environment injection: wrap helper processes or inject environment variables needed for first-run initialization.

The key limitation is that most compatibility problems only surface at runtime. There’s no static scanner that lists every possible runtime assumption. That’s why a test-driven approach — run, observe failures, apply targeted fixups, iterate — is the practical method for converting apps.

Community and maintenance

Microsoft has open-sourced PSF and maintains a growing catalog of community-contributed fixups. Over time, that shared library reduces conversion effort for common patterns, but for many enterprise apps you’ll still need custom configuration or bespoke fixups.

Final Thoughts

MSIX delivers major operational advantages, and PSF provides a pragmatic compatibility bridge for many Win32 apps. Combined with InstallShield’s packaging, validation, and automation capabilities, organizations can accelerate MSIX adoption without large rewrites — using PSF to unblock immediate needs while planning longer-term modernization where required.

Try InstallShield’s MSIX tools: start a free trial to convert your first package and see how PSF integration can simplify compatibility work.

Additional Resources

Microsoft’s Official Documentation on PSF

Package Support Framework on Github

The Windows ecosystem is evolving, and ARM-based devices are no longer niche. With Microsoft’s continued investment in Windows on ARM and hardware partners delivering increasingly powerful ARM64 devices, software vendors must ensure their installers are ready to support this growing platform.

At Revenera, we’ve been closely tracking this shift. InstallShield already enables you to build and deliver reliable installations for ARM-based Windows devices, without forcing disruptive changes to your existing installer projects.

Why ARM-Based Windows Devices Matter

Historically, Windows applications were built almost exclusively for x86 and x64 architectures. That assumption no longer holds true.

Windows on ARM brings tangible benefits:

• Longer battery life, ideal for mobile and lightweight devices
• Always-on connectivity
• Increasing availability of enterprise-grade ARM64 hardware

Importantly, Microsoft has made ARM adoption easier by providing built-in x86 emulation, allowing many existing Win32 applications to run seamlessly on ARM-based systems. For software vendors, this lowers the barrier to entry, but installers still need to behave correctly on ARM platforms.

Will Existing x86 or x64 Applications Run on ARM?

Yes, most x86 applications run on ARM-based Windows without modification, thanks to Microsoft’s emulation layer. Windows dynamically translates x86 instructions into ARM64 instructions at runtime, enabling compatibility with existing binaries.

From an installer perspective, this means:

• Your application binaries may already work
• Your installer must still be architecture-aware, especially when writing files, registry entries, and system components

That’s where InstallShield comes in.

Building ARM-Compatible Installations with InstallShield

If you are already using InstallShield to build Win32 installers, the good news is simple:

You can continue using InstallShield today, no redesign required.

InstallShield supports building installations that work correctly on ARM-based Windows systems, including native ARM64 installers where required.

Basic MSI Projects: Key Configuration

For applications targeting ARM64 devices, InstallShield provides explicit support through Basic MSI projects. To ensure correct behavior on ARM-based systems, configure the following in your project:

• Template Summary: Arm64
• Schema: 500

These settings are available in the Software Information view of the project and ensure Windows Installer recognizes the package as ARM64-aware.

Once configured, your installer:

• Installs files into the correct native locations
• Writes registry data appropriately
• Avoids WOW6432Node redirection issues common with misconfigured packages

What “Works Automatically” vs. What Requires Attention

From an engineering standpoint, it’s important to be clear about boundaries.

Works Out of the Box

• Installing x86-based applications on ARM via Windows emulation
• Running existing InstallShield setups on ARM devices
• Standard MSI logic, conditions, and sequencing

Requires Correct Configuration

• ARM64-native file locations
• Registry placement (32-bit vs. 64-bit components)
• Template Summary and Windows Installer version alignment

Looking Ahead: Native ARM Support Is Expanding

ARM adoption is accelerating, and so is InstallShield’s investment in this space.

Native ARM64 support in InstallShield continues to evolve, with ongoing enhancements focused on:

• Improved ARM-specific folder handling
• Cleaner native installations
• Alignment with newer Windows Installer capabilities

Whether ARM64 is part of your product roadmap, or already part of your customer base, now is the right time to validate your installer strategy. Contact us for more information.