Protecting App Screens, Icons, and Your Interface as a Registered Design

A product team ships a banking app with a checkout flow that took eight months to get right. The spacing, the colour system, the way a single card animates as it slides into the wallet, all of it feels effortless to the user and was anything but to build. Four months after launch a competitor releases something that is, screen for screen, the same flow. Same layout, same icon grammar, the same little animation. The code is different, so a copyright claim over the source feels shaky. The brand name is untouched, so trademark does not bite. The team is left with the uneasy sense that the most valuable thing they made, the actual look of the product, was sitting in the open the whole time.

This is the gap that registered design protection is built to close. In Turkey, the visual appearance of a graphical user interface is protectable as an industrial design under the Industrial Property Code (Law No. 6769). A screen layout, an icon, a set of icons, the styling of a control, even the frames of a short animation can be registered, and a registration gives you an exclusive right over that appearance that does not depend on proving anyone copied your code. Software teams routinely protect the engine and forget the face. The face is often the part users actually recognise, and it is registrable on its own terms.

An interface is an industrial design, not a patent and not just code

The first thing to settle is vocabulary, because the wrong word sends people down the wrong path. In the United States this right is called a design patent, and that label leaks into Turkish conversations where it does not belong. Turkey, like the European Union and the United Kingdom, protects product appearance through an industrial design register, not through the patent system. What you are filing is an industrial design application, and the thing it protects is the way your interface looks, not how it works.

The definition that matters is broad on purpose. A design is the appearance of the whole or a part of a product resulting from its features: lines, contours, colours, shape, texture, ornamentation. A graphical user interface fits squarely inside that. The screen is a product feature with a designed appearance, and the icons, menus, and visual styling that make it up are exactly the kind of ornamentation the law has in mind. You are not protecting the function of a button. You are protecting the considered, particular look of it.

Two conditions decide whether that look can actually be registered, and they are the same two that govern any design. The appearance has to be new, meaning no identical design has been made available to the public before your filing date. And it has to have individual character, meaning the overall impression it gives an informed user differs from what already existed. An interface assembled entirely from default platform components and stock icons struggles on individual character, because an informed user has seen that exact impression a hundred times. A screen with a distinctive layout and a custom visual language clears the bar comfortably. Knowing where your interface sits on that line is the first real question, and a proper industrial design registration starts by assessing it honestly rather than filing on hope.

Novelty is fragile, so the launch screenshot is the enemy

Software gets shown early. Designers post screens on Dribbble, founders demo the beta at a pitch event, the marketing site goes live with a full gallery of the product weeks before the design application is filed. Each of those is a public disclosure, and disclosure is what destroys novelty. The version of your interface the whole internet has already seen is, by the moment you file, no longer new.

Turkish law softens this with a grace period. A disclosure made by the designer, or by someone who got the design from the designer, within the twelve months before the filing date does not count against the design's own novelty. That window is a safety net, not a strategy. It does not protect you against a third party who saw your public screens and filed something similar first, and it does not exist at all in some other countries where you might later want protection. The disciplined move is to file before the wide reveal, or at the very least to know the clock has started the day the first real screenshot goes out. Treating the launch as the trigger for the design filing, rather than an afterthought to it, is the difference between a clean registration and a scramble.

What you actually submit: views, states, and the dotted-line trick

A design registration is only as good as the representation you file, because the images define the scope of the right. For a physical product you submit views from several angles. For an interface the logic is the same but the content is different, and getting the set of views right is where the real craft sits.

Single screens and icons

The cleanest case is one screen or one icon. You submit a clear representation of the screen as the user sees it, or the icon on its own. If the protection you care about is the layout, the arrangement of elements rather than any particular content inside them, you can show the structural design and use a recognised convention to signal which parts are claimed and which are merely context. The widely used technique is to render the features you are claiming in solid lines and everything you are disclaiming, the surrounding device frame, sample text, placeholder content, in broken or dotted lines. That dotted-line disclaimer lets you protect the skeleton of a screen without locking yourself to one set of words or images sitting inside it.

Icon sets as multiple designs in one application

An icon family is rarely one design. Each icon is its own appearance, and the efficient route is a multiple application, which lets you file a batch of related designs together in a single filing rather than one form per icon. A coherent set of interface icons, all in the same visual language, can go in as a group. This keeps a system of icons protected as the system it is, and it is markedly cheaper than treating each one as a separate case.

Animated and transitional interfaces

An animation, a transition, the way a control morphs as a user acts on it, can be protected too, and the approach is to capture it as a sequence. You file a series of still images representing the key frames of the movement, enough of them that the progression of the design is clear from start to finish. The registered design then covers that animated appearance as a sequence of states rather than a single frozen image. Motion design has become a real part of how products are recognised, and it is protectable when it is documented as the ordered sequence it is.

Where the design right stops and software copyright takes over

Design registration is powerful precisely because it is narrow. It protects appearance, and only appearance. It says nothing about the code that renders the screen, the logic underneath it, or the architecture of the application. The moment a dispute is about how the software is written rather than how it looks, you are in a different body of law.

That other body of law is copyright. In Turkey, software is protected as a literary work under the copyright regime, and that protection covers the source and object code, the expression of the program itself. It arises on creation without any registration, though recording the work creates dated proof of authorship that is valuable in a dispute. A clear-eyed software team protects both layers deliberately, because they guard against different attacks. A software copyright registration defends the code a competitor might lift or decompile. The design registration defends the interface a competitor might rebuild from scratch, with entirely original code, simply by copying what they see on screen.

The opening scenario is exactly the case where the line matters. The competitor wrote their own code, so the copyright in your source was never touched. But they reproduced the appearance, and a registered design over the screen and its key animation gives you a right aimed precisely at that. One register protects the thing under the hood, the other protects the thing the user looks at. Relying on either alone leaves a flank open, and for a product whose whole advantage is how it feels to use, the design flank is the one most often left undefended.

Protection should scale with where the product goes

A Turkish design registration covers Turkey. A product that lives in an app store lives everywhere at once, which makes the geography question immediate rather than eventual. If the app is meaningfully used in Europe, a registration covering the European Union protects the same interface across the whole bloc through a single filing, and a Turkish applicant can pursue it through the unitary EU design registration. For protection that needs to reach several countries at once, the international route runs through the Hague System for international design registration, which lets you seek protection in multiple member territories from one application built on your home filing. The right sequence depends on where your users actually are and where a copycat would hurt most, not on filing everywhere by reflex.

The practical takeaway is simpler than the law around it. The look of your product is an asset you can own, the same way you own the name and the code, and an interface left unregistered is an asset sitting unguarded. If you are about to launch, or you have already shipped and never protected the design, talk to us before the grace period runs out, and we will map which screens, icons, and animations are worth registering and file the design that fits the product.