MacPaw Brings On-Device AI to Its App Store

MacPaw Begins Offering On-Device AI Capabilities to App Developers

On August 5, MacPaw and Liquid AI announced a partnership: MacPaw will bring Liquid AI’s on-device model capabilities into its app store ecosystem, allowing developers to run AI features on users’ devices instead of sending requests and data to the cloud by default.

MacPaw’s own AI assistant, Eney, will be among the first implementations. The two companies are developing a local version that will perform some understanding, retrieval, and task processing directly on consumer hardware such as Macs.

This is not simply about adding another chatbot to the app store. More significantly, MacPaw is attempting to turn model inference into a foundational capability provided by the app distribution platform: developers design the product and user experience, while the platform and Liquid AI handle the models, runtime, and device adaptation.

If this capability can be made reliably available, its significance for Mac app developers could approach that of Apple’s integration of Core ML into its operating systems—except that MacPaw has chosen a technology stack more focused on generative AI, agents, and device-native models.

The Local Version of Eney Is a Testing Ground, Not the End Goal

Eney is an AI assistant built by MacPaw for Mac users. Its goal is not merely to answer questions, but to understand user intent and invoke app or system capabilities to complete tasks. These could include freeing up storage space, finding files, processing documents, or linking multiple apps into a workflow.

This type of assistant is naturally suited to on-device inference.

For one thing, it needs access to a great deal of local context: filenames, app states, system settings, clipboard contents, and even the user’s activity history. Uploading all of this information to the cloud would create significant privacy, compliance, and network costs. For another, a system-level assistant cannot wait for a remote model to respond every time the user clicks a button. The latency would directly undermine the user experience.

The value of a local version of Eney therefore goes beyond “being able to chat offline.” It gives MacPaw a way to validate an end-to-end pipeline:

1. Whether models can run reliably across different generations of Mac hardware;
2. Whether memory usage, power consumption, and time to first token can be kept under control during inference;
3. How models can invoke system tools securely;
4. How apps can download, update, and roll back models;
5. Whether the system should switch to a cloud model when the local model is not capable enough.

Once this pipeline works within Eney, MacPaw can package it as an SDK, runtime, or platform service for third-party developers in its app store. Eney is more like a showcase; developer infrastructure is the real business this partnership is aiming to build.

Liquid AI Is Not Selling “Smaller Chat Models”

In recent years, Liquid AI has consistently emphasized being device-native—that is, accounting for device constraints from the model design stage, rather than first training a massive model and then forcing it onto end-user devices through quantization, distillation, and pruning.

This distinction is critical.

Traditional cloud-based large models prioritize parameter count and cluster throughput, with the default environment being a data center with abundant GPU memory. On-device models face entirely different constraints: unified memory may be limited to 8GB or 16GB, support for operators varies across CPUs, GPUs, and NPUs, and apps must compete for resources with browsers, video conferencing software, and development tools.

In this environment, a model that “can run” is far from being suitable for a production product. Even if a model can generate text on a Mac, it has little practical value for ordinary applications if it takes dozens of seconds to load, consumes most of the available memory at runtime, or keeps the fans spinning at high speed.

Liquid AI’s approach is to design models around memory efficiency, hardware awareness, and low-latency inference. Its LFM family covers tasks such as text generation, reasoning, tool calling, and retrieval. Some of its small reasoning models can run within a memory budget of less than 1GB. Its previously released 350M-parameter multilingual embedding and ColBERT models have also reduced on-device retrieval latency to the millisecond level.

This means MacPaw can try breaking an AI workflow into separate components:

• A local embedding model searches files, notes, and app data;
• A small generative model handles intent recognition, summarization, and structured output;
• A tool-calling model determines whether to perform a system action;
• Only complex reasoning or extremely long-context tasks are sent to a cloud model.

This hybrid architecture is far more complex than “sending every question to a large-model API,” but it is also better aligned with the cost structure of desktop applications. By keeping large volumes of frequent, simple, privacy-sensitive tasks on the device and using cloud computing only for a small number of difficult tasks, developers can control both the user experience and their bills.

For Developers, the Platform Layer Matters More Than the Models Themselves

On-device AI has never lacked models. What it truly lacks is a reliable delivery mechanism.

Developers can download quantized models from model communities or integrate MLX, Core ML, ONNX Runtime, or other inference frameworks themselves. But once they move into production, they quickly encounter a series of problems unrelated to model quality: model files can range from hundreds of megabytes to several gigabytes, so how should they be distributed with the app? What precision should be used for different chips and operating system versions? How can background inference avoid competing with foreground tasks for resources? How can developers ensure that older devices do not crash after a model update?

If MacPaw merely provides a model download portal, the value of this partnership will be limited. A genuinely useful platform needs to cover at least four layers of capability.

1. A Unified Runtime

Developers should not have to adapt separately to Intel Macs, different generations of Apple Silicon, and different memory configurations. The platform should select the appropriate model version, quantization precision, and execution backend based on the device’s capabilities, and proactively degrade performance or functionality when resources are insufficient.

2. Model Distribution and Updates

Models should be decoupled from application code, with support for on-demand downloads, incremental updates, signature verification, and rapid rollbacks. Otherwise, every model update would require resubmitting an application package several gigabytes in size, which would be unacceptable to both users and developers.

3. Permission and Tool-Calling Boundaries

The fact that an on-device model can access local data does not mean it should have unlimited permissions. Tool calls generated by the model must undergo structured validation, permission confirmation, and auditing—especially for high-risk actions such as deleting files, sending emails, or changing system settings.

Moving inference onto the device can reduce the risk of data exfiltration, but it does not automatically solve prompt injection, unauthorized tool calls, or erroneous execution.

4. Cloud Fallback Mechanisms

Small models excel at clearly defined, narrow-domain tasks, but they generally still lag behind frontier cloud models in complex reasoning, open-ended writing, and long-context analysis. A mature platform must allow developers to configure routing conditions—for example, deciding whether to switch to the cloud based on task type, confidence level, network status, and user authorization.

MacPaw has not yet disclosed the complete form of its SDK, pricing model, list of supported devices, or a specific timeline for opening the platform to third-party developers. At this stage, it is therefore more appropriate to view the announcement as confirmation of a platform strategy rather than as a mature product that developers can integrate without restrictions.

Why Should an App Store Handle Model Inference?

At first glance, model runtimes and app stores appear to be two separate businesses. The former belongs to AI infrastructure, while the latter focuses on distribution and subscriptions. For MacPaw, however, combining the two makes strong business sense.

Generative AI is making applications increasingly resource-intensive. Developers need to distribute not only code, but also models, prompt templates, vector indexes, and tool definitions. At the same time, the cost of calling cloud models will continue to erode the margins of small applications. If a productivity tool that charges only a few dollars per month frequently calls cloud-based large models for every active user, it can easily end up in a situation where the more active its users are, the more money the developer loses.

By providing on-device inference at the platform level, developers can shift fixed costs onto hardware that users have already purchased. MacPaw, meanwhile, can use this capability to differentiate its app store: rather than merely serving as a storefront for downloads and subscriptions, it can provide developers with an AI runtime environment.

This is also one of the few openings MacPaw has in competing with Apple’s official ecosystem. MacPaw is unlikely to surpass Apple in system permissions or hardware integration, but it can attract independent developers through more open model selection, faster product iteration, and more flexible commercial policies.

This path also carries clear risks. Apple already has Core ML, MLX, and deeply integrated system-level foundation model frameworks, while controlling the hardware, operating system, and app review gateway. If MacPaw merely adds another distribution layer around Liquid AI, it could easily be replaced by Apple’s official tools or other cross-platform inference frameworks.

MacPaw must prove that it is providing a service developers genuinely want to depend on—not merely a co-branded model offering.

On-Device Does Not Mean Completely Replacing the Cloud

This partnership can easily be interpreted as “AI moving back from the cloud to local devices,” but a more accurate assessment is that AI applications are moving toward tiered computing.

The advantages of on-device models are clear:

• Data stays on the device by default;
• They do not depend on network access, making response latency more consistent;
• Frequent calls do not incur inference fees that accumulate by the token;
• They can access the device’s real-time state, making them suitable for system-level assistants;
• Personalization data can remain on the user’s device.

The limitations are equally clear:

• Model capabilities are constrained by memory and power consumption;
• Performance varies significantly across devices;
• Model packages can substantially increase storage usage;
• Local updates and security maintenance are costly;
• The user’s hardware bears the computing costs that would otherwise be assumed by a cloud provider.

The more realistic product model is therefore neither fully local nor fully cloud-based, but a collaboration between device and cloud. File retrieval, classification, intent recognition, and routine tool calls are handled locally, while tasks requiring higher accuracy, larger contexts, or real-time knowledge are sent to the cloud.

This creates new engineering requirements for developers. In the past, integrating AI might have meant little more than calling an HTTP endpoint. Now, developers must simultaneously manage the local model lifecycle, resource scheduling, request routing, privacy permissions, and cloud fallback. If the platform cannot hide this complexity, on-device inference will struggle to achieve widespread adoption.

Assessment: The Direction Is Right, but Success Will Depend on Engineering, Not Benchmarks

MacPaw’s decision to work with Liquid AI suggests that it does not view on-device AI as an add-on feature, but is instead attempting to embed inference capabilities into its app ecosystem. Liquid AI, meanwhile, gains a rare consumer distribution channel through which it can demonstrate that its models can support real-world applications, not merely perform well on benchmarks.

The direction of this partnership is sound. Desktop assistants need low latency, local context, and privacy protections, while app developers need to move away from a cost structure based entirely on per-token fees. Compared with building yet another chatbot wrapper, providing developers with an on-device runtime clearly offers greater long-term value.

However, it is still too early to draw firm conclusions. Small parameter counts and strong benchmark scores address only the first part of the on-device AI challenge. Device compatibility, model updates, permission management, crash recovery, and device-cloud routing are what will determine whether ordinary developers are willing to deploy this technology in production applications.

What matters next is not how many more benchmarks Liquid AI wins, but whether MacPaw releases a stable SDK, whether developers will be free to choose their own models, and to what extent the local version of Eney can complete real-world tasks without relying on the cloud.

If these questions receive clear answers, MacPaw’s app store could be among the first to evolve from an “app distribution platform” into an “AI application runtime platform.” If not, the partnership will remain little more than an impressive technical demonstration.

References

• Liquid AI: The American Story of an On-Device AI Unicorn: Additional background on Liquid AI, its on-device model strategy, and its commercialization approach.

The information about the events described in this article is based on public reporting from August 5, 2026, and publicly available materials from both companies. Due to restrictions on reference-link domains, links to original reports and official websites outside the permitted domain range are not included at the end of this article.