LG webOS app development

Your model-year floor is really a Chromium floor

Most platforms make you infer this. LG states it outright:

Platform version	Release year	Web engine
webOS TV 26	2026	Chromium 132
webOS TV 25	2025	Chromium 120
webOS TV 24	2024	Chromium 108
webOS TV 23	2023	Chromium 94
webOS TV 22	2022	Chromium 87
webOS TV 6.x	2021	Chromium 79
webOS TV 5.x	2020	Chromium 68
webOS TV 4.x	2018-2019	Chromium 53
webOS TV 3.x	2016-2017	Chromium 38
webOS TV 2.x	2015	WebKit 538.2
webOS TV 1.x	2014	WebKit 537.41

Read the bottom half slowly. A 2016 LG television runs Chromium 38, an engine from 2014. A 2018 set runs Chromium 53. Neither has the JavaScript or CSS your team writes by default, and no build step fully rescues you — polyfills cover syntax, not missing platform behaviour or the memory budget of a nine-year-old television.

So "support back to 2016" is not a percentage of your audience. It is a decision to maintain a second, older front end, and to test it on hardware nobody in the office owns.

The number worth arguing about is the Chromium version, not the model year. Pull the webOS version distribution from your analytics, find where the curve actually falls off, and set the floor there deliberately.

LG webOS app development for broadcasters lands on the older end more often than digital-native services do, for the same reason it does on Samsung: the audience that came across from linear television owns the television it came with.

webOS is an HLS platform

This is the one that surprises teams arriving from Android.

LG's specification presents webOS TV as built around HLS, and does not list MPEG-DASH or Smooth Streaming among its supported protocols. HTTP and HTTPS are supported, with HTTP/2 from webOS TV 5.0; HTTP/3 is not supported. AES-128 encryption with HLS goes back to webOS TV 1.0.

If your packaging is DASH-first — which it will be if Android drove your original build — then LG is not a reuse of your existing pipeline. It is an additional HLS ladder, with the encoder cost and the storage cost that implies.

That is a packaging decision with a real invoice attached, and it belongs in the scoping conversation rather than in sprint four.

DRM, and the line that sets your floor

Both major systems are available, but not everywhere:

• PlayReady is available across webOS TV versions from 1.0, reaching version 4.6 on webOS TV 26. LG recommends the post-delivery method rather than the pre-delivery method for OTT services. Non-persistent licences are not available on webOS TV 3.0, 3.5 and 4.0.
• Widevine Modular is available from webOS TV 3.0, reaching version 17 on webOS TV 26. The line that matters: L1 / HW_SECURE_ALL is supported on webOS TV 3.5 or higher. Widevine Classic is deprecated as of webOS TV 23.

Put that beside the Chromium table and the floor sets itself. If your studio agreements require Widevine L1 — most premium catalogues do — then webOS 3.5 is the oldest you can serve, and everything below it is not a cheaper tier, it is an unservable one.

LG webOS app development for vod platforms usually settles here first, because a licensed catalogue makes the DRM requirement non-negotiable and the rest of the scope follows from it.

You cannot test DRM on the emulator

This is the constraint that reorganises a test plan, and it is stated plainly in LG's own documentation: PlayReady and Widevine work on actual webOS TV devices and do not work on simulators or emulators.

So every piece of protected playback — licence acquisition, output protection, persistent versus non-persistent licences, the behaviour when a licence expires mid-stream — is verifiable only on real hardware. The emulator remains useful for layout, navigation and the parts of the app that are not the point of the product.

Two consequences worth planning for:

1. You need real LG sets, plural, spanning your supported range. A single 2025 television proves nothing about the 2018 one your floor commits you to.
2. Device access becomes a schedule dependency. The bug that only appears on webOS 4.x appears two weeks before launch, and the answer cannot be "reproduce it on the emulator".

This is exactly the problem our own tooling came out of, and it is why we treat the device matrix as part of the plan rather than something QA sorts out later.

The supported route onto a real set is Developer Mode: the television and the developer's machine on the same network, the webOS CLI installed, and an LG Developer site account to enable it. Worth setting up on day one, because it is a prerequisite for testing anything that matters.

Budget hardware before you budget engineering. Buying the sets is cheap next to discovering, late, that the only machine which reproduces your DRM bug is a television nobody has.

The store renamed itself, and changed how people sign in

Two things moved recently, and both are the kind of detail that dates a vendor's proposal.

On 29 April 2026, LG published a notice that the LG Content Store would be renamed LG Apps. It is a branding change rather than a new submission process, but if a studio's proposal still calls it the LG Content Store throughout, you now know when they last looked.

The one with engineering attached came on 8 June 2026, when LG announced that simple login using certain social accounts would be discontinued for LG Apps. That narrows the set of authentication options available to your viewers, and sign-in is already the worst experience on any television — typing an email address with a remote is the single most abandoned step in a TV app.

Which is why device-code pairing against a phone or laptop is worth building rather than avoiding. It removes the remote from the equation entirely, and it does not depend on which social providers a platform still supports this year.

One more, easy to miss and expensive to discover: the apps available for installation depend on the TV model and on the LG Services Country setting. If you are launching across several markets, that setting is part of your test matrix, not a detail of the user's preferences.

What carries over from your other TV apps

The honest split, if you have a Samsung Tizen app already:

Carries over. Both are web apps driven by a remote, so your catalogue, API layer, entitlement model, design system and most interface logic move across with modest work. Your focus and navigation model, because the input device is the same shape. Your analytics.

Does not. Packaging and store submission. The device media APIs, because Samsung's AVPlay and LG's media pipeline are different interfaces to the same idea. DRM integration, per the section above. And your performance assumptions, because the two platforms' oldest supported engines are not the same vintage.

Teams reliably underestimate the second list and describe LG as "a week of work after Samsung". It is more than that, and less than a rebuild.

LG webOS app development for telcos adds one more: an operator deal often means appearing in a bundled line-up or a launcher position, which is a commercial negotiation running alongside the build.

What drives the cost

A range that fits everyone helps nobody, so here is what actually sets the number.

1. Your Chromium floor. webOS 6.x and newer is a different project from webOS 3.x and newer, and it is the largest single multiplier here.
2. Whether you already produce HLS. If you are DASH-only today, add the packaging work.
3. Your DRM level. L1 sets the floor at webOS 3.5; anything else changes the device matrix you must own and test on.
4. Whether Samsung is already done. Sharing a codebase with an existing Tizen app is the biggest saving available on this platform.

Tell us those four and you get a real number rather than a range that covers everyone.

Who builds it

Everything above is how we actually work rather than a checklist assembled for this page.

We build our own tooling. VibeView came out of exactly the problem this page describes — that shipping to every platform means testing on every platform, and on TV that means real hardware rather than an emulator that cannot even run your DRM. When a project needs middleware rather than only an app, MwareTV is a technology partner of ours, so both sides come from one conversation.

And the people who scope your project are the people who build it. There is no account layer between you and the engineer who knows which Chromium version your oldest supported set is running.

Where webOS sits in the rest of your rollout

LG is almost always the second smart-TV platform, after Samsung, and the pairing is the most efficient in the whole rollout: two web apps, one remote-driven interface model, one shared catalogue and entitlement layer.

Scope them together and the second costs a fraction of the first. Scope them a year apart and you will pay twice for the same decisions.

We build these, end to end

The webOS app, the HLS and DRM integration, the focus and navigation model, the packaging and LG Content Store submission, real-device testing across your supported range, and the maintenance passes when a new webOS version lands.

If you already have a Samsung app, we will tell you honestly how much of it moves and how much does not, before you commit to a number based on someone's guess that it is "mostly the same".

Send us your webOS version distribution, whether you produce HLS today, and your DRM requirements. You will get back a scope and a number rather than a brochure. If you do not have the version distribution yet, start there — it decides more about this project than any choice we will make together.