you dont have access to this feature - firefly edit with a prompt video tool

Hi Kevin,

Thank you for the detailed response.

I do appreciate your time and agree with your point regarding regional regulations and Adobe’s obligation to comply with the laws of each jurisdiction in which it operates.

Where legislation genuinely restricts a particular AI model or capability, such as voice replacement, translation or manipulation of audiovisual content, I fully understand that Adobe must respect those requirements, even when they limit functionality for users. That is a legitimate and necessary constraint, and I have no disagreement with Adobe taking a responsible approach to legal compliance.

I also take your point regarding Kling. I can understand why some enterprise clients may restrict particular AI providers based on their own security, data-governance, privacy or jurisdictional risk assessments, including concerns surrounding Chinese-developed services such as Kling, which is developed by Kuaishou.

The same principle applies more broadly. Organisations may impose different policies on external AI services such as ChatGPT, Claude, Gemini, Copilot, DeepSeek and others. Likewise, generative-video platforms such as Kling, Google Veo, OpenAI Sora, Runway and Adobe Firefly may each present different technical, contractual, data-governance and enterprise-security considerations.

If Adobe or an enterprise restricts a particular model for a genuine legal, security, contractual, data-processing or regulatory reason, I can understand and respect that.

In fact, I think those examples illustrate my point rather well: they identify specific reasons for restricting functionality. 

A global browser market-share percentage does not.

My disagreement is therefore not with regulation, security or responsible AI governance. It is specifically with the browser argument.

Market share is not the same as compatibility

Quoting Chrome at approximately 68% and Safari at approximately 16% sounds compelling until we examine what those statistics actually represent.

Those are broad global browser-market figures covering an enormous population across different devices and operating systems, including Android phones, Windows PCs, corporate environments, schools and ordinary consumers, many of whom may never use an Adobe professional product.

That does not necessarily tell us anything about the browser preferences of Adobe Creative Cloud customers, particularly professional users working on macOS.

The more relevant question would therefore be:

What percentage of Adobe’s actual Creative Cloud customers on macOS use Safari, Chrome, Firefox, Edge, Brave and other browsers?

Unless Adobe-specific figures are available, I don’t think general worldwide browser statistics should be presented as though they represent Adobe’s professional customer base.

More importantly, market share may reasonably influence development priority, but it does not, by itself, explain technical incompatibility.

I completely understand that developers have finite resources. Different browser engines implement technologies differently, and sophisticated AI applications can depend upon APIs, codecs, WebGPU, WebAssembly, authentication, sandboxing, security policies, media handling and third-party services that may not behave identically across Chromium, WebKit and Gecko.

That is software engineering, and it is entirely understandable.

But if one of those differences prevents a feature from working in Safari, then that should be the explanation.

For example:

“This model requires a browser capability that Safari/WebKit does not currently provide.”

“The third-party AI provider currently supports or certifies only Chromium-based browsers.”

“Safari’s implementation of a required API currently prevents this functionality.”

“This capability is unavailable because of a regional legal restriction.”

“Enterprise security requirements prohibit this particular model.”

Those are meaningful explanations that developers and customers can understand and evaluate.

“Chrome has more users” is not a technical explanation.

It establishes popularity. It does not establish incompatibility.

Browser choice should remain with the customer

A browser is no longer simply a window through which somebody views a webpage. It forms part of a much broader technology environment.

People deliberately choose browsers for reasons including privacy, security, accessibility, performance, battery efficiency, extensions, operating-system integration, corporate policy and personal preference.

An Apple user may deliberately choose Safari because it is Apple’s native browser and is deeply integrated into macOS, iPhone and iPad, including passwords and passkeys, Keychain, Handoff, Apple Pay, tab synchronisation and privacy technologies such as Intelligent Tracking Prevention.

A Firefox user may choose Mozilla because of features such as Enhanced Tracking Protection and Total Cookie Protection.

A Brave user may deliberately choose it for its approach to trackers, cross-site cookies and fingerprinting.

A Chrome user may prefer Google’s extensive compatibility, extensions and ecosystem integration.

An Edge user may prefer its integration with Windows, Microsoft accounts and Microsoft 365.

Every one of those choices is legitimate.

This is therefore not an argument that Safari is “better” than Chrome, nor that Chrome or Edge are inherently insecure. Both Google and Microsoft invest heavily in browser security.

It is an argument for consumer choice and interoperability.

Some people actively value Google’s integrated ecosystem, including Search, Gmail, YouTube, Maps, Drive, Photos, Calendar and Gemini. Others deliberately prefer not to integrate their browsing environment as closely with those services.

Likewise, some people appreciate Microsoft’s integration of Edge with Microsoft accounts, Bing, Copilot, Microsoft 365 and OneDrive. Others deliberately choose a different browser environment.

Neither group is wrong.

But an Adobe customer should not unnecessarily have to make an unrelated decision about adopting another company’s browser ecosystem simply to obtain functionality from an Adobe product or service for which they are already paying.

Adobe and Apple also have a long shared history

There is another point that I think is relevant here.

Adobe and Apple share a long and important history in professional creativity, design and publishing. For decades, Mac users have been highly visible users of Adobe products such as Photoshop, Illustrator, Acrobat and, later, Creative Suite and Creative Cloud.

At the same time, Apple’s prominence in graphic design, publishing, photography and video provided an influential professional platform on which Adobe applications became deeply established.

I would not suggest that either company owes its success solely to the other. Their relationship has benefited both companies, as well as the creative professionals who adopted their products.

Given that history, I think it is entirely reasonable for today’s Mac customers to expect Safari and macOS to remain meaningful considerations as Adobe develops its web-based and AI services, even if Safari is not the world’s dominant browser.

Consider the same market-share reasoning elsewhere

Imagine being told:

“Gmail has greater market share, so this Adobe service works properly only with Gmail. Outlook users should simply create a Google account.”

Or:

“WhatsApp is more widely used, so iMessage users should install WhatsApp if they want this functionality.”

Or:

“TikTok performs better in this market, so Instagram users should simply move to TikTok.”

The popularity of one service does not, by itself, explain why another service cannot be accommodated.

Popularity and interoperability are not the same thing.

There is also a potential circularity in the market-share argument

Suppose developers increasingly optimise sophisticated web applications for Chrome because Chrome has the largest market share.

Users of other browsers then encounter services recommending that they install Chrome or Edge to access particular functionality.

Some of those users consequently switch.

Chrome’s market share increases.

Developers can then point to that increased market share as further justification for concentrating development on Chromium.

The reasoning risks becoming self-reinforcing:

“We optimise for it because most people use it, and more people use it because software is optimised for it.”

I am not suggesting Adobe intentionally created such a cycle. I am illustrating why market share alone should not become justification for reducing interoperability.

Healthy competition on the web depends, at least in part, upon major software providers making reasonable efforts not to turn the dominant browser engine into a de facto requirement where no genuine technical necessity exists.

Safari is not an obscure browser

Safari is Apple’s first-party browser and is deeply integrated into macOS, iOS and iPadOS.

For an Apple customer who has deliberately chosen that environment, using Safari is an entirely reasonable choice regardless of whether Safari occupies first, second or tenth place on a worldwide browser-market-share table.

More importantly, Adobe itself recognises Safari alongside Chrome, Firefox and Edge within its published browser requirements for Adobe web services.

That makes the appropriate question even clearer.

If Adobe generally supports Safari, but a particular AI feature does not function within it, the question should not be:

“How many people globally use Safari?”

It should be:

“What specifically prevents this feature from operating in Safari?”

Perhaps Kling or another third-party provider imposes the restriction.

Perhaps that provider currently certifies only Chrome-based browsers.

Perhaps WebKit lacks a required capability.

Perhaps there is a genuine security or performance issue.

Perhaps licensing, data governance or enterprise policy is involved.

Perhaps regional legislation prevents the feature from being offered.

Any of those could constitute a legitimate explanation, and if that is the case, I would genuinely welcome the technical explanation.

That is ultimately the distinction I am making

I am not suggesting that Adobe must make every experimental AI model work perfectly in every browser, operating system and jurisdiction immediately.

That would be unrealistic and unfair to the developers responsible for implementing rapidly evolving technologies.

Nor am I questioning Adobe’s obligation to comply with legislation or the legitimate concerns enterprises may have regarding individual AI providers.

Quite the opposite. Those are precisely the explanations that should be communicated clearly.

If the limitation is legal, identify the legal limitation.

If it is an AI-provider restriction, identify the provider restriction.

If it is an enterprise-security decision, explain the security requirement.

If it is a WebKit limitation, identify the browser capability involved.

If Safari genuinely cannot provide something the model requires, explain what is missing.

Developers will understand those explanations, and informed customers will respect them.

But global Chrome market share does not answer any of those questions.

For a professional software company serving customers across Windows and Apple platforms, I believe the better principle is straightforward:

Market share can determine priority. Technical requirements can determine compatibility.
Legislation can determine availability.
Security and governance can determine access.
But popularity alone should not determine customer choice.

Adobe built much of its reputation by giving creative professionals powerful tools and allowing them to choose how those tools fit into their workflows.

I believe that philosophy should extend, wherever technically reasonable, to the browser through which those services are delivered.

So I would respectfully return to the original issue:

What is the actual technical, regulatory, security or provider-specific reason that this particular Adobe AI functionality cannot operate through Safari?

If there is a genuine limitation, I am entirely willing to understand and accept it.

But if the answer is simply that Chrome has a larger worldwide market share, then I don’t believe that addresses the issue.

Browser popularity is a statistic. It is not, by itself, a technical justification for browser dependency.

Thanks again for your time,

Gmstr

It shouldn’t be the case considering what is expected.