Engineering note
Submitting a Tizen app to the Samsung TV store
Writing the application is the part you planned for. Getting it published is the part that quietly costs you a fortnight. Almost none of that time goes on code: it goes on assets at exact dimensions, on wording that survives review, and on discovering requirements one rejection at a time. This is what we wish had been written down before our first submission.
Treat the submission as a deliverable, not a formality
The common failure is sequencing. Teams finish the application, then start assembling store assets, and discover that several of them require decisions nobody has made: what the application is called in the store, what it claims to do, who it is rated for, and what its legal terms say. Each of those is a conversation, and conversations do not fit in the gap before a launch date.
Build the store pack alongside the application instead. The assets are derived from your brand, the description is derived from your positioning, and both exist long before the code is finished.
The assets, and the one rule that catches everyone
Seller Office wants artwork at specific dimensions, and it rejects anything that is off by a pixel or in the wrong format. Confirm the current numbers against Samsung's documentation before you build the pack, because they do change between platform versions, but the shape of the problem is stable:
- An application icon, square, used in the launcher row.
- A wide launcher tile with a different aspect ratio to the square icon.
- Screenshots at full panel resolution, 1920 by 1080, as JPEG rather than PNG.
- A background or promotional image, again at panel resolution.
The rule that catches people is the wide tile. It is not the square icon stretched, and it is not your logo lockup with the wordmark already in it. The store composes your application name next to the tile, so a tile that already contains the name renders the name twice. Design the wide tile as the mark alone, with the breathing room the composition expects.
Screenshots are a product decision disguised as an asset
They must be real captures at full panel resolution, which means a build that is finished enough to photograph. That sounds obvious until you realise the screenshots are what the reviewer uses to decide whether your description is accurate, and what a browsing customer uses to decide anything at all.
Capture them from the application running on a television rather than a browser window scaled to 1920 by 1080. The rendering differs in ways reviewers notice, and the detail you lose is exactly the detail that makes a TV interface look like a TV interface.
Write the description for the reviewer first
A store description is read by two audiences with opposite needs. The customer wants to know whether it does what they want. The reviewer wants to know whether you are claiming something you cannot deliver, or something the store does not permit.
The reliable approach is to describe the software and not the content. A media player plays media the user provides; it does not supply channels, and saying it does invites a rejection you cannot argue your way out of. Avoid naming third-party services or formats as features. Describe the capability, state plainly what the user needs to bring, and let the feature list carry the specifics.
Answer the age rating for what the software does
The rating questionnaire asks about the application, not about everything reachable through it. Answer for the software's own behaviour and be consistent with your description and your terms: a mismatch between the three is one of the easier ways to fail review, and it is entirely avoidable.
If your answers imply user-supplied content, your legal terms need to say so too. Reviewers do read them.
Generate the pack, do not draw it
We produce every store asset from a single set of vector masters through a build script. One command regenerates the entire pack, byte for byte, at every required size and format. A brand tweak is a re-run rather than an afternoon in a graphics editor, and the second submission costs minutes instead of days.
This is worth doing even for one application. You will submit more than once. Rejections, store refreshes, a new platform version with a new asset size — each one is free if the pack is generated and expensive if it is hand-drawn. One caution from our own build: if the script rasterises SVG masters, pin the font tooling and verify the output, because a missing font silently produces artwork with the text replaced rather than an error.
Budget the calendar, not the effort
Review takes weeks, not days, and the first submission is rarely the last. Plan the launch date from the first submission, not from the code freeze, and submit early enough that one rejection does not move it.
If you are building the application as well as submitting it, the Smart TV player case study covers what the platform constraints do to the code itself.
FAQ
Frequently asked questions
How long does Samsung review take?
Plan in weeks and expect at least one round of feedback. The duration is less predictable than the cause: most first-round rejections concern store assets, the age rating or the wording of the description rather than the application. Submitting a complete, internally consistent pack is the only lever you control.
Can I reuse my mobile app icons?
No, and it is worth understanding why rather than just resizing them. Television artwork is viewed from three metres on a panel that may be showing it next to a dozen competitors, and the launcher composes your application name alongside the tile. An icon designed for a phone home screen is too detailed, too small in its margins, and often contains a wordmark that will be duplicated.
Do I need a separate build for LG webOS?
A separate package, yes; a separate codebase, no. Both platforms run web applications and the shared surface is large. What differs is packaging, the store submission process and the media playback interface. Plan for two submissions and one application.
What is the most common avoidable rejection?
A description that claims more than the software does. The second is an asset at the wrong dimensions or in the wrong format. Both are caught by one careful pass before you submit, which is considerably cheaper than a review cycle.
Keep exploring
Related technologies and services
Have a project in mind?
Let's build something exceptional.
Tell us where you are and where you want to go. We'll reply within one business day with honest next steps, even if that means pointing you elsewhere.