DEV Community: Maxym Babenko

Building VisualSnag and Why AI Tools Need Clear Visual Context

Maxym Babenko — Thu, 25 Jun 2026 08:05:53 +0000

Hi! My name is Maksym. For a long time, my professional career was connected with UX/UI and product design, but over the last year I have been focusing more and more on building my own products.

At first, I was building iOS and macOS apps with Swift. Later, I moved to JavaScript and built several apps for Jira and Confluence. After that, the logical thing would have been to stop, focus on marketing the products I had already built, and avoid opening a new repository for at least a few months.

But in practice, when you work on your own ideas, things rarely happen that rationally. Very often, a new product does not start with a big strategy. It starts with a problem that repeats itself often enough that one day you can no longer ignore it.

That is how the idea for VisualSnag appeared.

The idea

Recently, I have been working a lot with AI tools for development and design: ChatGPT, Claude Code, Codex, Figma Make, and other similar tools. They already help a lot with logic, application structure, component generation, code, and fast prototyping.

But while working with these tools, I kept running into the same problem: the visual side of the generated interface often feels too generic. This is especially noticeable with tools like Claude Code.

The interface can be functional, responsive, and technically correct, but it often lacks a clear visual identity, a sense of brand, strong typography, color logic, rhythm, and composition.

Phrases like “make it modern,” “make it beautiful,” or “make it premium” do not give AI enough specific direction. Even for a human designer, these would be weak instructions without references, context, and a clearer explanation of the expected result. With AI, this becomes even more obvious, because the model tries to fill in all the gaps on its own and often chooses the safest and most typical solution.

I started thinking about how to make this process more precise.

If a person already has a website or an image reference that communicates the right mood, style, or visual logic, why not turn that reference into structured rules for further work with AI?

VisualSnag lets you paste a website URL or upload an image reference and get a ready-to-use visual system for AI-assisted building: colors, typography, layout rules, CSS variables, design tokens, a style brief, and AI prompts.

The idea is not to copy someone else’s website. The goal is to understand its visual logic and turn it into practical materials that can be used in your own project.

Why not just another prompt generator?

At first glance, VisualSnag could be described as a prompt generator for design. But I did not want to build another tool that simply returns a long text with generic phrases.

The problem of visual direction in AI-assisted development is broader than that. Users do not need only a prompt. They need specific anchors that can be transferred into the development process:

which colors to use;
what role primary, secondary, accent, and background colors should have;
what typography logic works for headings, body text, labels, and buttons;
what border radii, spacing, and interface density are typical for the reference;
what overall UI mood should be preserved;
which CSS variables can be used right away;
which prompt can be pasted into ChatGPT, Claude, Codex, Cursor, Lovable, or another AI builder.

That is why I see VisualSnag not as a prompt generator, but as a translator between a visual reference and practical rules for AI-assisted development.

A user may see a website or an image they like, but they cannot always quickly explain why it works. VisualSnag is meant to help extract not a surface-level similarity, but the visual structure behind the reference: colors, typography, composition principles, the character of UI components, and rules that can later be adapted to a new product.

Development

The name VisualSnag came from the idea of “snagging” or “catching” a visual style. I wanted the product to avoid sounding like another technical analyzer and instead have a simple metaphor: the user gives the tool a website or an image, and the service catches the style logic behind it.

After the idea, name, logo, and first screens were ready, I moved into development.

The stack I chose was:

Frontend

Vite, React, TypeScript, Tailwind CSS.

Backend

Node.js, Express.

Database

PostgreSQL.

ORM

Prisma.

Hosting

Railway.

URL analysis

Playwright / Chromium.

This stack made sense for several reasons.

First, I already had experience with JavaScript and TypeScript after building apps for the Atlassian Marketplace. Second, I needed speed and flexibility, not an overly complex architecture for the first version of the product. Third, Railway made it possible to quickly deploy both the application and PostgreSQL in one environment.

Vite and React gave me a fast frontend. Tailwind CSS helped me build the interface quickly while keeping control over the visual system. Node.js and Express covered the API layer.

Of course, this does not mean everything worked on the first try. Especially after Playwright and server-side Chromium entered the project.

How the product works

In the first version, I tried to make the user flow as clear as possible.

A user can:

Paste a website URL.
Upload one or more image references.
Start the analysis.
Receive a structured result.
Copy the needed blocks.
Download files for further work.

As an output, the product generates several types of results.

Style Brief

This is a short description of the visual direction. It explains the general character of the reference: mood, density, typography logic, color behavior, composition approach, and overall UI mood.

Colors

The service identifies the main palette and tries to distribute colors by role: background, surface, text, primary, accent, border, and so on.

This is important because a random set of HEX codes is not very useful on its own. It is much more helpful to understand what each color is responsible for.

Typography

A separate section describes the typography direction: headings, body text, buttons, labels, and accents.

It is not always possible or necessary to copy the exact font from a reference. More often, it is more important to understand the typography logic: geometric, editorial, tech, playful, minimal, high-contrast, or neutral.

Layout rules

This block describes the principles behind the interface layout: spacing, grid, density, container width, the character of cards, sections, CTAs, and visual rhythm.

Component DNA

This is an attempt to describe how UI elements behave within the style: cards, buttons, badges, inputs, sections, and navigation.

I wanted the output to be useful not only for simple landing pages, but also for more complex interfaces.

CSS Variables

The service generates variables.css, which can be used as a starting point for the frontend. It is not a final design system, but it gives a useful base layer for fast prototyping.

Design Tokens

tokens.json provides a structured format that can be used in AI tools, custom scripts, or design processes.

AI Prompts

VisualSnag also generates prompts for AI-assisted building.

The idea is that the user does not have to write the style instructions from scratch. They can immediately paste the generated description into ChatGPT, Claude, Codex, Cursor, Lovable, Figma Make, or another AI tool.

Downloads

The result can be viewed on the website, but it can also be downloaded as working files:

STYLE.md
variables.css
tokens.json

This is important because these files can become part of a real workflow. They are not just text on a screen. They can be copied into a project, sent to another AI tool, saved as documentation, or used as a starting point for further design and development.

Architecture

At the architecture level, I did not try to build a complex system in the first version. The main task was to create a stable path from input to output.

The flow looks roughly like this:

The user submits a URL or uploads an image.
The backend receives the request and creates a database record.
For a URL, the page analysis process starts.
For images, visual data is processed.
The data is transformed into an internal structured format.
A style brief, tokens, CSS variables, and prompts are generated.
The result is returned to the frontend.
The user copies the blocks or downloads the files.

PostgreSQL is used to store users, requests, statuses, results, and technical metadata.

I also spent time thinking about what data should and should not be stored. VisualSnag works with references, and references can be work-related, private, or temporary. I did not want the product to become an uncontrolled storage for everything a user had ever uploaded.

So I decided to store only what is needed for the product to work: authentication, exports, and access to previous results. Anything unnecessary should not end up in the database just because it is technically possible to store it.

Problems and solutions during development

During development, I ran into several technical and product challenges. They showed that even a tool that looks relatively simple from the outside can have many internal details.

1. AI output must be structured, not just nicely written

The problem: if you simply ask AI to describe the style of a website or an image, the result is often too general. It may be well-written, but not practical enough.

For example, a phrase like “modern and clean interface with strong visual hierarchy” sounds fine, but it does not provide enough material for actual development.

I needed an output that could be used immediately. Not just a description, but specific blocks: colors, typography, layout rules, CSS variables, tokens, and prompts.

The solution: I made the output as structured as possible. Each block has its own role and expected format.

If it is colors, the colors should have roles. If it is typography, there should be a breakdown by text types. If it is CSS variables, they should be ready to use. If it is a prompt, it should be written in a way that can be pasted into an AI builder without extra editing.

The main takeaway: AI inside a product should not simply generate text. It should return a predictable and useful artifact.

2. It is important to explain that the product does not copy websites

The problem: any tool that analyzes the visual style of a website can be misunderstood. I did not want to build a service for copying other people’s websites. That would not only be legally and ethically wrong, but also less interesting from a product perspective.

The goal is different: to help users understand the visual logic of a reference and adapt it to their own project.

The solution: I deliberately avoid phrases like “clone any website.” Instead, I use terms like visual system, style brief, design rules, and AI-ready prompts. These describe the product more accurately.

The service is not meant to transfer someone else’s website into your own project. It is meant to help read the style principles and turn them into a clear foundation for your own interface.

3. Running Chromium in production

The problem: for URL analysis, it is not enough to simply fetch HTML. The tool needs to work with the page as an actual rendered website. Styles, loaded fonts, computed styles, visual structure, responsiveness, and the way a page looks after JavaScript execution all matter.

For this, Playwright / Chromium is needed.

Locally, this approach works fairly smoothly. But in a production environment with containers, additional issues appear: system dependencies, fonts, permissions, memory, timeouts, and browser launch stability.

The solution: I configured the environment for Chromium, added the required dependencies, limited concurrency, and made timeout handling more careful. I also had to account for the fact that different websites load at different speeds, use different numbers of scripts, and behave differently during rendering.

4. Websites have very different structures

The problem: there is no single universal way to extract visual style from a website.

One site has well-structured CSS variables. Another uses Tailwind classes. A third one has inline styles. A fourth builds many visual elements through JavaScript or SVG.

Colors can be in CSS, background images, gradients, SVGs, or decorative elements. Fonts can load from different sources. Layout can change significantly depending on viewport, cookies, or A/B tests.

The solution: I did not try to build a system that perfectly understands every property of every website. Instead, I chose a practical approach: collect the most useful signals from the DOM, computed styles, visual structure, and page screenshot, then convert them into a clear style format.

For this type of product, absolute technical reproduction of every pixel is less important than a useful interpretation of the visual system.

5. The interface must make sense to both designers and developers

The problem: VisualSnag sits between design and development.

For designers, references, style, colors, composition, and typography are important. For developers, CSS, tokens, prompts, exports, data structure, and the ability to use the result quickly in their workflow are important.

If the product is too design-oriented, developers may find it less clear. If it is too technical, it may lose users who think through visual references.

The solution: I split the output into two levels.

The first level is human and visual:

Style brief
Colors
Typography
Layout rules
Component DNA

The second level is practical and technical:

CSS variables
Design tokens
AI prompts
Downloads

This way, the user can either quickly understand the style or immediately take concrete materials for work.

What I did not build in the first version

I deliberately did not try to turn VisualSnag into a large platform right away.

The first version does not include:

team workspaces;
a full project library;
a Figma plugin;
a browser extension;
a marketplace of ready-made style systems;
complex collaboration features;
automatic generation of a finished website from a reference.

At the start, it was important to test the main hypothesis:

Do people need a tool that turns a website or image reference into a practical visual system for AI-assisted development?

That is why the first version focuses on the core scenario:

Provide a reference.
Get structured style output.
Copy a prompt or download STYLE.md, variables.css, and tokens.json.
Use it in an AI-assisted workflow.

During development, I once again became convinced that AI needs not only a functional task, but also clear visual context.

A reference is not an instruction by itself. It needs to be broken down into specific rules: colors, typography, rhythm, layout, components, spacing, and accents.

That is why useful AI output must be structured, not just presented as a long text without clear sections. When the result is separated into Style Brief, CSS variables, design tokens, and AI prompts, it becomes much easier to use in a real project.

What is next

The nearest goal for VisualSnag is to collect feedback from people who actually use AI tools to create websites, applications, and interfaces.

I want to understand:

how useful the Style Brief is;
whether the CSS variables are accurate enough;
whether tokens.json is convenient to use;
which export formats are missing;
which prompts work best for different AI builders;
whether users need to compare several references at once.

Potentially, the product can move in several directions:

deeper URL analysis;
better screenshot processing;
comparison of multiple references;
separate output formats for Cursor, Claude, Codex, Lovable, Bolt, Framer, and Webflow;
a library of saved visual systems;
team workspaces;
a Figma plugin;
a browser extension for quickly analyzing the style of any page.

VisualSnag is not meant to copy other people’s websites. It is an intermediate layer between a visual reference and AI-assisted development. Its goal is to make visual direction clear, structured, and usable in a real project.

Links

Try VisualSnag here:
https://www.visualsnag.com/

Contact me directly:
max.babenko@typeswitch.net

I built a simple way to publish Confluence pages to the web

Maxym Babenko — Thu, 07 May 2026 08:27:08 +0000

Hey DEV community 👋

I recently built Public Pages for Confluence, a small app for teams that write content in Confluence but need an easier way to publish some of it publicly.

The idea came from a simple problem: Confluence is great for writing internal docs, product notes, guides, and knowledge base content, but publishing that content to the public web often means using another CMS, a heavy site builder, or copying the same content somewhere else.

I wanted to make that workflow simpler.

What it does

Public Pages for Confluence lets you publish selected Confluence pages as public web pages.

It is useful for things like:

help center articles
knowledge base pages
product guides
release notes
public documentation
customer-facing content

The goal is not to replace a full documentation platform. It is more focused: keep writing in Confluence, choose which pages should be public, and publish them to the web.

Why I built it

A lot of teams already have useful content inside Confluence, but it stays hidden from customers, prospects, or search engines.

Native public sharing can work for simple access, but it often feels limited when you need a more polished public page, SEO metadata, analytics, branding, or a custom domain.

So I built a lighter workflow for publishing Confluence pages externally without moving content into another system.

Current features

publish selected Confluence pages publicly
clean public URLs
SEO title and meta description
Google indexing controls
automatic sitemap support
GA4 analytics
Search Console verification
logo and site name branding
custom domain support

It is also free for teams up to 10 users.

Marketplace link:
https://marketplace.atlassian.com/apps/356517983/

I would love feedback from anyone who uses Confluence for documentation, help centers, product guides, or public knowledge bases.

Especially curious about this question:

Would you prefer a lightweight publishing tool like this, or do you usually need a full site builder for public documentation?

Essential macOS Apps for Developers in 2025

Maxym Babenko — Thu, 29 May 2025 07:28:20 +0000

MacOS has always been a solid choice for developers. It combines the stability of Unix underpinnings with elegant design and powerful hardware. But what really supercharges your workflow isn’t just the system itself — it’s the apps you run on it.

In 2025, the developer toolset on macOS is richer than ever. Whether you're coding, testing APIs, writing notes between sprints, or just living in the terminal, there’s an app that can make your day smoother. Here's a curated list of four standout tools every developer should consider.

1. Visual Studio Code

The All-in-One Code Editor for Every Stack

Visual Studio Code (VS Code) has been at the top of every developer’s list for years — and it’s still going strong in 2025. Created by Microsoft, it’s more than a text editor; it’s a full-fledged development environment that’s still lightweight, customizable, and shockingly fast.

VS Code supports pretty much every modern programming language out of the box or through extensions — from JavaScript and Python to Rust and Go. Its built-in Git tools, powerful debugger, and intelligent autocompletion (thanks to IntelliSense) make it ideal whether you’re building websites, automating tasks, or diving into machine learning.

The 2025 updates brought even more polish: security improvements like mandatory extension signature verification, smarter sidebar controls, and deeper workspace customization. It also runs natively on Apple Silicon, which means performance is smooth even on the most intensive projects.

If you want one editor that can handle it all — VS Code still wears the crown.

2. Peeknote

**
Quick Notes and Snippets Without the Noise

Sometimes you don’t need a sprawling knowledge base. You just need a clean space to think, write, and move on. That’s where Peeknote shines.

Peeknote is a minimalist macOS app designed for developers who want to quickly jot down ideas, to-dos, or snippets of code — without getting lost in tabs, folders, or settings. It's built to be fast, native, and pleasant to use. The interface is distraction-free, but smart: it supports syntax highlighting for multiple programming languages, making it great for saving and reusing code fragments.

There are no overwhelming features, no clutter — just a reliable companion always ready to open and capture a thought. And because it’s lightweight, it doesn’t hog your memory or CPU. Keep it open while you code, and you’ll forget it’s even there — until you need it.

For devs who live in ideas and jump between tasks, Peeknote is like a digital sticky note... only better.

3. iTerm2

**
The Terminal, Leveled Up

The default Terminal on macOS is... fine. But developers who spend a lot of time in the command line know there’s a world of difference between fine and fantastic. Enter iTerm2 — the terminal replacement you didn’t know you needed (until you use it).

iTerm2 packs a punch with features like split panes (finally!), session restoration, hotkey windows, extensive customization, and even support for advanced scripting. You can search across terminal output, bookmark sessions, and tweak the visual design down to your liking.

The latest 2025 release, version 3.5.13, brought fixes for annoying bugs and better compatibility with macOS Ventura and Sonoma. Whether you're SSH-ing into servers or running Docker containers locally, iTerm2 helps you do it all faster and more comfortably.

It’s one of those tools that quietly improves your daily routine — and once you switch, there’s no going back.

4. Postman

**
Master Your APIs Without Leaving Your Mac

If you work with APIs — and let’s be honest, who doesn’t in 2025 — Postman remains a must-have. It’s no longer just a tool for testing GET requests; it’s a full API development and collaboration platform.

Postman lets you build, test, document, and monitor APIs in a visual and intuitive way. You can organize endpoints into collections, share them with your team, automate tests, and plug it all into your CI/CD pipeline. The new Spec Hub helps centralize and manage your API specs. And with the Postman CLI, you can now lint, test, and secure APIs directly from the command line.

This year’s updates also improved performance and reliability on macOS — with full support for macOS Catalina and newer. Whether you’re building backend services or just trying to debug a webhook, Postman makes the process easier, faster, and more collaborative.

Final Thoughts
Choosing the right tools makes all the difference in a developer’s day. Some apps help you code better. Others help you think clearer. And a few make the whole experience more enjoyable.

Whether you’re living inside VS Code, managing servers through iTerm2, sketching ideas in Piknote, or wrangling APIs with Postman — each of these apps earns its place on your Mac. They don’t just help you get work done — they help you do your best work.

So if you haven’t tried them yet, maybe it’s time to see what your Mac is truly capable of.

Time in Status for Jira: Best Practices That Actually Work in 2025

Maxym Babenko — Tue, 20 May 2025 07:33:47 +0000

Agile teams often look productive on the surface. Standups are happening, boards are moving, everyone is busy. But then the sprint ends and a large chunk of the work is still not finished.

If this sounds familiar, you’re not alone. You open your Jira board and see issues scattered across “In Progress,” “In Review,” or “Waiting for QA.” It's frustrating, because the team was working. So what happened? Where exactly did the process slow down?

This is where tracking Time in Status can become one of the most useful things your team does.

Why Time in Status Is More Than a Nice-to-Have

At first, measuring how long an issue sits in each status might seem like overkill. But it often reveals things your team didn’t realize were happening.

Instead of relying on memory or assumptions, you get actual data to help you:

Identify where issues are spending too much time
Catch slow or unclear handoffs
Spot hidden bottlenecks

Plan future sprints based on what really happened, not what you expected

Here are a few common patterns teams notice once they start tracking this:

The "In Review" column gets crowded at the end of each week
QA only starts testing in the last days of the sprint
Some tasks stay “In Progress” even though they’re actually blocked and no one notices

Once you can see these patterns, it becomes easier to address them.

What Real Teams Have Discovered

Case 1: Too Much Time Waiting for Review

One team realized that some issues were spending more time in “Ready for Review” than in development. The reason? Developers didn’t want to stop coding to do reviews, so they postponed them. QA ended up getting a flood of issues on Friday.

How they fixed it:

Set up a daily 30-minute “review time”
Encouraged devs to do reviews earlier in the sprint
Balanced the testing load more evenly

✅ Result: Reviews started happening faster. QA got a steadier flow. And the team felt a lot less pressure on Fridays.

Case 2: No One Noticed the Blockers

Another team committed to 10 stories. Only 4 were finished. The others were scattered across statuses like “Blocked,” “Ready for QA,” and “In Progress.”

When they looked at the time data, they saw:

Two tasks had sat in “Blocked” for three days
A few tickets were ready for review, but no one was tagged
Everyone had been focused on their own work and missed what was stuck

What they changed:

Started tagging the next person responsible in comments
Added a short daily sync focused just on blockers

✅ Result: In the next sprint, the average waiting time dropped by nearly half.

Why Manual Tracking Isn’t Worth the Effort

Some teams try to track Time in Status with spreadsheets, filters, or Jira exports. That usually doesn’t work well.

Why? Because it’s:

Easy to forget or update late
Not integrated into the real workflow
Too slow to be useful in real-time

💡 That’s why more teams are turning to tools that track it for them, right inside Jira.

A Simpler Way to See What’s Really Going On

Flow Time Report is a lightweight Jira Cloud app that automatically shows how long an issue spent in each status, who moved it, and when.

Right in the issue panel, your team can see:

Total time in each status
Entry and exit timestamps
Who transitioned the issue
Visual indicators that show whether a task is on track, at risk, or overdue
Export options to CSV, JSON, Markdown, or plain text

No setup. No dashboards. You immediately see how work moves through your Jira workflow.

How Teams Use This in Daily Work

This kind of visibility helps improve more than just reports.

➡️ During Sprint Planning

Look at timing from past sprints to set more realistic expectations for each issue type.

➡️ At Daily Standups

If something has been “In Progress” for more than two days, bring it up. Is it stuck? Does someone need help?

➡️ In Retrospectives

Discuss issues that spent the most time in any single status. Why? And what could make that faster next time?

➡️ For Team Conversations

Use the data to support better conversations about process, collaboration, and ownership.

Not About Micromanagement — It's About Flow
Some people get nervous about tracking things like Time in Status. It might feel like someone is watching over their shoulder.

But when used well, this kind of tracking actually gives teams more control. It lets people see how the process works as a system, and where it breaks down.

In one case, a QA team mentioned they were always the last to know when something was ready. After looking at the time data, the devs started tagging them directly in comments. A small change, but it made a big difference.
You Can Try It for Free
Зміст статті
Flow Time Report
Flow Time Report is free for small teams (up to 10 users) and has a 30-day free trial for everyone else.

🔗 Try it on the Atlassian Marketplace

If your team cares about improving how work flows, cutting down stress, and finishing what gets started, this is a good place to begin.

Jira #Agile #Scrum #Kanban #TimeInStatus #WorkflowOptimization #TeamPerformance #ProductivityTools #JiraApps #SoftwareDevelopment #AgileDelivery

Best Risk Management App for Jira (Scrum & Agile teams)

Maxym Babenko — Mon, 17 Mar 2025 09:52:23 +0000

👋 Hey everyone!

I’m excited to share Risk Radar, a powerful Jira Cloud app that helps teams assess and manage risks directly within Jira issues.

🔍 What is Risk Radar?
Risk Radar helps you identify potential risks associated with Jira issues right when they are created or edited. By assessing risks early, you can prioritize issues more effectively, reduce setbacks, and make smarter decisions.

Key Features:
▶️ Instant Risk Check: Evaluate risk levels as you create or update Jira issues.
▶️ Clear Risk Levels: Automatically classify tasks as low, medium, or high risk based on likelihood, impact, and complexity to fix.
▶️ Easy Jira Integration: Works effortlessly within your existing Jira setup—no hassle.

Why Use Risk Radar?
✅ Assess risks early: Evaluate and address risks when creating or editing issues.
✅ Make Smarter Decisions: Prioritize tasks with real-time risk insights.
✅ Enhance Team Collaboration: Improve transparency with clear risk indicators for every issue.

Get Started:

📥 Download: Risk Radar on the Atlassian Marketplace
🎥 Quick demo: Watch the Video
📖 Documentation: Read the Guide

I’d love for you and your team to give Risk Radar a try and share your feedback. Your insights will help me continue to improve and make the tool even more useful!

Issue with Empty Window Appearing on App Launch for macOS App - Help Needed

Maxym Babenko — Sat, 23 Nov 2024 09:03:55 +0000

I've been struggling with a problem for the past couple of weeks, and I can't seem to figure out the cause. I'm developing an app that allows users to easily switch languages on macOS. The app is ready, and I submitted it for review, but the problem is that Apple has been unable to approve it for the past two weeks due to an issue.

Upon launching the app, an empty window/container appears, but I cannot reproduce this issue on my own Macs (M1, M2, M3). On my machines, the app works perfectly and launches without the empty window appearing.

Does anyone know how I can identify and resolve this issue? I’ve attached a screenshot of the empty window that needs to be removed from the code, as well as a snippet of the code that might be responsible for it.

I would greatly appreciate any advice or suggestions on how to fix this, as I’m unable to reproduce the error on my end.

Thanks in advance for your help!

Screenshot:

@main
struct LanguageSwitcherApp: App {

    @NSApplicationDelegateAdaptor(AppDelegate.self) private var appDelegate

    var body: some Scene {
        Settings {
            EmptyView()
        }
        .commands {
            CommandGroup(after: .appInfo) {
                Button("Show Language Switcher") {
                    appDelegate.showLanguageSwitcher()
                }
            }
        }
    }
}

class AppDelegate: NSObject, NSApplicationDelegate {
    private var statusItem: NSStatusItem?
    private var languageSwitcherPanel: LanguageSwitchPanel?

    func applicationDidFinishLaunching(_ notification: Notification) {

        statusItem = NSStatusBar.system.statusItem(withLength: NSStatusItem.variableLength)
        if let button = statusItem?.button {
            button.image = NSImage(named: "icon_top")
            button.action = #selector(showMenu)
            button.target = self
        }

        showLanguageSwitcher()
    }

    @objc private func showMenu() {

        let menu = NSMenu()

        menu.addItem(NSMenuItem(title: "Close Type Switch", action: #selector(closeApp), keyEquivalent: "q"))

        statusItem?.menu = menu
        statusItem?.button?.performClick(nil)
        statusItem?.menu = nil
    }

    func showLanguageSwitcher() {
        guard languageSwitcherPanel == nil else { return }

        let panel = LanguageSwitchPanel()
        let hostingController = NSHostingController(rootView: LanguageSwitchView())
        panel.contentView = hostingController.view
        panel.makeKeyAndOrderFront(nil)
        NSApp.activate(ignoringOtherApps: true)

        languageSwitcherPanel = panel
    }

    @objc private func closeApp() {
        NSApp.terminate(nil)
    }
}

I tried testing the app on my MacBook models (M1, M2, M3) and all of them functioned as expected, launching the app without any additional windows appearing. I also checked the code for any unintended window launches or containers and could not find any issues.

I expected the app to launch without any extra empty windows or containers, but when Apple tested it, they encountered an issue with an empty window appearing upon launch.

Type Switch: A Convenient Language Switcher for macOS

Maxym Babenko — Mon, 11 Nov 2024 16:51:54 +0000

As a long-time Apple enthusiast who works with English, French, and Polish, I’ve always found macOS's default language-switching tools to be less than ideal for managing multiple languages.

The process feels clunky, and I wanted something more intuitive and efficient. That’s why I decided to create Type Switch — a simple, powerful language-switching tool designed to make multilingual typing effortless.

What is Type Switch?

Type Switch allows users to quickly and easily switch between all languages installed on their system. With a customizable button that can be adjusted for size, color, and opacity, the app is designed to offer a seamless and intuitive experience tailored for multilingual users.

Key Features:

Quick toggling between installed languages.
Customizable button (size, color, opacity).
Optional sound and speech feedback for each language.
Clean, minimal design with a floating switch panel.
Launch at startup for easy access.
Keyboard hotkey [⌃ Ctrl] for quick switching.

Download app: [https://apple.co/3ZmYZXH]

Video: [https://youtu.be/RjXJG9876Zs]

iOS Game “POP FRENZY!” Launches Today!

Maxym Babenko — Wed, 30 Oct 2024 13:18:07 +0000

🎉 Hey everyone! 🎉

I just released my new iOS game, POP FRENZY! It’s a fast-paced game that invites players to engage in the art of popping, inspired by the fascinating physics of particle movement.

Game Features:

Physics-Inspired Gameplay: Interact with elements that reflect the dynamics of particle movement for a distinctive experience.

Fast-Paced Action: Quickly pop matching elements within a time limit, testing your reflexes and quick thinking.

Multiple Game Modes: Enjoy various modes, such as the original mode and "Ghost" mode, each offering different challenges and strategies.

Accessible for All Ages: Easy to pick up, the game provides enjoyment for all skill levels while offering depth for those seeking mastery.

I’d love to hear any comments or feedback! If anyone is interested in downloading it for free, feel free to message me for a promo code!

Download Game: https://apps.apple.com/ua/app/pop-frenzy/id6736933847

Gameplay : https://youtube.com/shorts/RZ_eloa6c_4?si=fDG16KGj0j_4tOBN

Mergeometry! a new iOS game reimagining 2048

Maxym Babenko — Wed, 16 Oct 2024 19:16:37 +0000

Hey everyone!

I just released my puzzle game called Mergeometry, and I’m pretty stoked about it. I wanted to give a fresh take on the classic 2048 game, and I think I’ve done just that with two unique merging modes:

Form Merging Mode: You combine shapes and try to outsmart the game to score points.

Evolution Mode: Here, you merge elements and guide the evolution of life, starting from molecules and going all the way to humans and beyond.

I also added some fun features:

You can customize the grid size and throw in a bomb mode if you’re feeling adventurous.
There are several game modes like Classic, Timed, and Reverse to keep things fresh.

Would love any thoughts or feedback if you decide to give it a go!

Download: https://apps.apple.com/ua/app/mergeometry/id6736862420
Demo: https://www.youtube.com/watch?v=pvWXsenawP4

I just launched it, so I’m still figuring things out. Would love any thoughts or feedback if you decide to give it a go!