Why is it hard to decide whether to replace a designer's downloaded font or buy a license after an App gets an infringement complaint?

Bottom line first: When an App gets an infringement complaint over images or fonts, the problem is usually not the act of a designer finding assets online. It is that the asset source was not logged, the license scope was not checked, and the replacement cost was not assessed in advance. Whether to replace it or buy a license mainly depends on whether the asset is a core visual and how large the current usage scale is. Based on 2026 mobile project delivery experience, these issues are often found in bulk months after launch; with different handling paths, the timeline and cost commonly differ by several times (experience range).

Why do most of these complaints appear after launch?

Infringement monitoring is done in bulk. Rights holders or agencies scan app stores and public channels in bulk using image fingerprints and font characteristics, and an App only comes into view after it has a certain number of downloads. This means the timing of a complaint has nothing to do with your development schedule; it may appear months after launch, when no one on the team still remembers who found those images. In 2026, some monitoring methods still rely mainly on bulk scanning, so receiving a letter after launch is not unusual.

A more common reason is that assets were treated as temporary placeholders during development. Images in the design file were used first, the system font was used first, and the plan was to replace them before launch, but when the schedule got tight, they went live as is. Replacing an image during development and replacing one after launch are completely different workloads: the former means changing the design file, while the latter means rebuilding the package, going through app store review, and waiting for users to upgrade. That is also why many teams knowingly leave risks untouched for now.

• Placeholder assets were not included in the pre-launch checklist, so no one was accountable for where the image came from.
• License screenshots and purchase records were scattered on the designer's local computer; once personnel changed, they could not be found.
• Outsourcing contracts only stated that assets were provided by the client, or only stated that assets were compliant, without specifying what proof to deliver at acceptance.
• Small elements such as icons, background textures, and illustrations are easily overlooked, but they are also subject to copyright.

How do you judge whether an asset can actually be used commercially?

The standard is not whether it can be downloaded for free, but whether the license terms cover your method of use. Embedding an image in an App is a distribution act, and many assets that only allow personal use or non-commercial use fail at this step. Fonts are more granular: common licenses are priced by number of Apps, installed base, or term. The same typeface can differ greatly under different license plans, so before signing, check clearly whether it covers one App or one account.

Another easily overlooked point is attribution. Some free assets allow commercial use but require attribution; the terms specify the attribution location and format. If the terms require it and you do not do it, that is also non-compliance. Conversely, license documents from legitimate stock image libraries or type foundries usually state the license scope, number of endpoints, and term of use. These documents are the proof you can present at acceptance and the basis for quickly self-certifying during internal review.

• Clearly commercial-use permitted, no additional conditions: The terms state commercial use is allowed and there are no attribution requirements; risk is relatively low. Before use, confirm the current version on the official license page.
• Free but requires attribution: Usable in commercial projects, provided you provide attribution per the terms; missing attribution is usually treated as unauthorized use.
• Personal or non-commercial use only: Not suitable for an App with commercial purposes; changing the use does not change this condition.
• Licensed from a legitimate stock library or type foundry: The license document states scope and term; fees are often based on asset quantity or endpoint scale. For a single typeface, the typical range is several hundred to several thousand yuan per year (experience range; subject to official quotation).

A four-step check to clarify assets before launch

Rather than wait to receive a letter and then dig through old records, manage assets as deliverables just like APIs and accounts. The four-step method below can be followed directly in a project; the point is to lock down two things, source and proof, without relying on any one person's memory.

1. Build a ledger: For every image, typeface, and icon, record the source link, download date, and license type in a shared spreadsheet rather than on a personal computer.
2. Archive proof: For free assets, save screenshots of the license page and the original terms; for paid assets, save the order and license document, named with the project name and date.
3. Assess replacement cost: Divide assets into two categories, core visuals and replaceable small elements. Use original or licensed assets for core visuals as much as possible, and prioritize resources with no additional conditions for small elements.
4. Check before launch: Before building the release package, have someone outside the design role spot-check against the ledger, focusing on fonts and icons, and submit for review only after confirming nothing is missing.

The third step is often skipped, but it determines how reactive you are when something goes wrong. If all assets are tied to core visuals, replacement means redesigning, rebuilding the package, and going through review again; if only a few small elements are at risk, handling it is a minor change. A common practice in projects is to include copyright proof together with source code and account ownership in the delivery checklist, with the client receiving them all at acceptance. That way, there is a basis for who can replace assets later and who checks after replacement.

After receiving an infringement letter, what paths are available?

Receiving a letter does not mean you have to pay immediately. Do one thing first: verify whether the assets the other party claims are actually in your current live version, and whether similar assets might have been misidentified. After confirming, which path to choose mainly depends on three things: whether the asset is a core visual, how large the current usage scale is, and whether the other party demands that you stop using it or pay for a license.

• Direct replacement: Suitable for non-core visual assets. The timeline is typically one to two weeks, including design, packaging, and submission for review. The cost is mainly labor and release workload, usually lower than the cost of buying a license (experience range).
• Buy a license: Suitable for core visuals or assets already used at scale. You need to discuss scope and term with the rights holder; the timeline ranges from a few days to several weeks, and the fee is negotiated based on usage scale.
• Negotiated settlement: Suitable for scenarios with large download volume and high value in continued use. There is no uniform standard for the amount; it usually depends on usage scope and whether use was stopped promptly, and is ultimately subject to written confirmation by both parties.

One thing you should not do: delay and do nothing. The common sequence is letter first, then platform complaint, and only later litigation. Delaying often causes the fact that you knew about the issue to be repeatedly factored into consideration, making you more passive. Conversely, if after checking you find that you did not use the assets claimed, or you have complete license proof, organizing the proof into a clear timeline statement is usually enough. That is also the value of the ledger mentioned earlier.

A delivery-site experience: the cost of handing over asset proof two weeks late

Constraints: A content community App already live. The first version was delivered by an outsourcing team; the designer used two fonts found online and several accompanying images. The contract only stated that assets were compliant, without specifying what proof to deliver. During project acceptance, the client also did not request license documents item by item, and the App went live after source code and accounts were handed over.

What was done: In the fourth month after launch, we received a letter from the font rights holder's agency. After stepping in, we first checked the renamed fonts and usage scope in the live version, and confirmed that one typeface was indeed mainly used for titles and buttons, making it a core visual. We then divided the assets into two categories, replaceable and needing a license, and handled the title font through license negotiation while replacing the button and icon fonts first. Result or cost: License negotiation to written confirmation typically took two to three weeks, and replacing the fonts from design to packaging to review typically took seven to ten days; if the font license proof had been collected at acceptance, the rework in this step could usually be reduced by more than half (experience range).

Applicable scenarios and boundaries

Suitable situations: projects where asset sources are scattered, multiple people collaborate, in-house and outsourced work are mixed, and the App is already live with a stable download volume. The investment to build an asset ledger once is usually within one to a few person-days, making it a low-cost action. For products preparing their first launch, adding asset checks to the pre-launch checklist has clearer benefits than remediating after launch.

Situations that do not really need a separate process: internal-only tool Apps used by employees, not published to an app store, and not distributed externally have less asset compliance pressure, but it is still not advisable to directly copy clearly protected content; for one-off campaign pages whose assets are all original to the brand or already purchased, you can simply reuse the existing brand asset library and check along the way. The boundary to remember is: asset compliance is not something finished once before launch; images and fonts that operations replace later are also in scope. So the real dividing line is who can replace assets, who checks after replacement, and whether this process has been defined in advance.

FAQ

If the App uses free commercial-use fonts, can it still be complained about?

It may still be scanned, but you can usually self-certify. The key is whether you can produce proof that the license page states commercial use is permitted, and that the version used matches the terms. If you cannot produce proof, the other party generally treats it as unauthorized.

If an outsourced App has an asset infringement issue, should we go after the outsourcing team or bear it ourselves?

It depends on how the contract is written. If assets were provided by the developer and the contract stipulates asset compliance, the developer is responsible; if it only states that assets were provided by the client, the client bears it. It is safer to include asset proof as an acceptance item when signing.

If we switch to open-source free fonts, is there no risk?

Risk drops significantly, but it is not zero. Some open-source fonts carry additional terms, such as requirements about font name or trademark use. When using them in an App name or logo, you still need to check the license statement separately.

If we replace all assets with licensed versions before launch, roughly how much more will it cost?

It depends on scale. A common approach is to replace fonts and icons, which are widely used, first, then handle images. For a single typeface, the typical license range is several hundred to several thousand yuan per year, and licensed images are priced per image or by subscription (experience range).

If you currently have an App preparing for review or already live, an easier starting point is to have the person responsible for design put together an asset ledger, first going through fonts and icons. When commissioning an external team, simply include asset proof in the handover checklist. In mobile delivery, Xiyue Company usually hands over copyright proof together with source code and account ownership to reduce the need to gather materials after launch; for projects where all assets are original or already purchased, just check against the existing brand asset library.