Should You Code Your Forge App or Let AI Generate It?

You can now get custom Jira apps in two main ways: write code with Forge UI Kit/Custom UI, or describe what you want and let an AI Apps Builder generate the Forge app for you. Both paths produce secure, native Forge apps, but they demand very different skills, timelines, and maintenance commitments.

Use code + UI Kit when you have developer capacity and need fine‑grained control; use an AI Apps Builder when you want to move fast, prototype safely, and empower Jira users who do not write code. In many teams, the best setup is a mix: AI to explore and validate ideas, code to harden what proves valuable.

How Forge apps actually work

Every Forge app follows the same basic flow: UI in Jira, a secure bridge, and logic running in Atlassian’s cloud. Jira renders your app inside an iframe on an issue view, project page, or dashboard, and your UI code handles user interactions in that iframe. You build the UI either with Forge UI Kit (pre‑built Atlassian components) or with Custom UI (your own React or other frontend) hosted by Forge.

The UI never talks to Jira “raw”; all app‑level Jira and external API calls go through the Forge backend via @forge/api, which enforces scopes and user permissions. Your UI calls backend functions using @forge/bridge (for example, invoke()), and resolver functions in the Forge runtime handle those calls, use requestJira(), talk to Forge Storage or SQL, and return results.

In a simple flow, a user clicks a button in an issue panel, the UI calls invoke("doSomething"), the resolver runs business logic and a Jira REST call, then returns data that the UI uses to re‑render.

Whether you write every line of this yourself or let an AI Apps Builder scaffold it for you, your app still runs inside this same architecture.

Coding your Forge app with UI Kit: control and cost

What “coding a Forge app” actually means

Building a Forge app with UI Kit is less about fancy visuals and more about clean flows and platform rules. You structure logic like: “When the user clicks this button, call the backend, fetch Jira data, maybe store something, and update the UI with the result.” In code, that means writing JavaScript for resolvers and triggers, managing state between UI and backend, and defining a manifest.yml that wires modules, resources, functions, and permissions.
​
With UI Kit, you describe your interface using Atlassian’s components instead of raw HTML and CSS, which makes apps visually align with Jira and other Atlassian products. Any action that needs Jira data, storage, or external APIs goes through the backend via invoke() and @forge/api, not directly from the browser, which keeps security consistent.

Learning curve and realistic timelines

Becoming productive with Forge is more than “install the CLI and go”; you need an intermediate level of JavaScript plus familiarity with Forge concepts. For someone who already knows JavaScript basics, a realistic progression looks like this:

1. ​After about 3–6 months of steady practice (5–10 hours/week), you can usually: understand Forge examples and starter apps, modify templates, and build simple apps (for example, an issue panel that reads fields and stores a small configuration).
2. Over 1–2 years of regular work on Forge, you reach the point where you can: choose sensible architectures without guessing every time, handle edge cases and tricky permission issues, and maintain apps over multiple releases without feeling like you are constantly starting over.

Once you know the platform, build times still vary with scope:

1. Simple app (one panel, one–two Jira calls)
   Example: an issue panel with a button, one requestJira() call, and a bit of storage.
   For an experienced Forge developer, this is often 1–3 days of focused work.

2. “Real” app (Custom UI, multiple resolvers, events, external API)
   Example: a custom dashboard or rich panel that pulls data from Jira and a third‑party service, with scheduled triggers.
   Getting to something stable and shippable usually takes 1–2 weeks.

3. Complex production‑grade app
   Example: multiple screens, queues for background work, performance tuning, security reviews, and robust error handling.
   These apps are measured in months and usually involve a small team, not one developer.

Most of this time is not spent typing code: it goes into clarifying requirements, reading Forge and Jira REST documentation, debugging deployment and permission issues, and iterating on UX so the app feels natural inside Jira.

UI Kit in 2026: why its history still matters

UI Kit 1 is gone, but the migration pain remains. UI Kit 1 is now fully deprecated and has not been functional since 28 Feb 2025, which means any UI Kit 1 modules show errors instead of real UI. That is why some older apps feel “partially broken” even though they remain installed: the backend logic may still run, but the UI surfaces backed by UI Kit 1 no longer render.
​
Migrating those apps to the latest UI Kit has required real refactoring work rather than a simple dependency bump:

1. Components such as Avatar and AvatarStack were removed and replaced by User and UserGroup.
2. Props changed on components like Badge and Button (for example, text moved into children, disabled became isDisabled, and icon props were renamed).
3. The manifest had to be updated to use resources (frontend entry files) plus render: native, instead of the older single-function field.

For Marketplace vendors, there has been another challenge: when the migration added or changed scopes, it forced a major version that each customer admin had to manually approve. In practice, that left some customers stuck on older, now‑broken versions simply because nobody had clicked “Approve new permissions” in time.

Visual stability and long‑term UI choices

Forge UI Kit is closely tied to Atlassian’s design system, which is a blessing for consistency and a risk for visual stability. When Jira’s global UI changes, UI Kit components can change too, without you shipping a new app version. A clear example is the component: when Jira rolled out a new navigation and updated tag styling, UI Kit tags went from solid coloured labels to subtle outlined chips, making colour cues much less obvious for users who relied on colour to scan quickly.
​
Partners have also highlighted that Atlassian has had several incompatible UI stacks over time: AUI, Atlaskit, UI Kit 1, and the current UI Kit—and each shift has carried migration costs. That history makes teams think carefully before investing heavily in UI Kit for large, long‑lived UIs.

The good news is that the latest UI Kit is far more capable than the original:

1. ​It ships with richer components such as charts, comment UIs, Pressable, and layout primitives like Stack, Inline, and Box, which make more complex layouts possible.
2. The Frame component lets you embed HTML, CSS, JavaScript, and even Custom UI‑style content inside a UI Kit screen, effectively giving you a blend of simplicity and flexibility.
3. The trade‑off is clear: UI Kit gives you opinionated, fast‑to‑build UIs that match Atlassian products, but you accept a higher chance of refactors when the design system or UI Kit API evolves, and you plan for scoped permission changes and admin approvals when you upgrade.

Letting AI generate your Forge app: Custom UI power from prompts

Start from your Jira use case, not from modules and manifests
An AI Apps Builder for Jira lets you start with the workflow you want to support, instead of starting with Forge concepts. Instead of thinking “issue panel vs dashboard vs global page” or “UI Kit vs Custom UI,” you write prompts like:

​“Create a gadget that shows issues assigned to the current user with due dates in the next 7 days, showing key, summary, status, and due date, sorted by nearest due date.”

“Create an issue panel that reads the issue’s due date and displays a live countdown timer, and if it is overdue, show ‘SLA breached’ in red.”

You do not decide which resolvers to use or which scopes to add; you describe what you want Jira to do, and the AI maps that intent to a Forge app structure.

What the AI Apps Builder actually does

A mature AI Apps Builder behaves like a Forge‑aware internal developer:

1. ​It chooses Custom UI for rich interactive experiences.
2. It generates frontend code, backend resolvers, and a manifest.yml with modules, resources, and scopes.
3. It validates that the app is consistent with Forge’s security and deployment rules and is ready to install.

From Forge’s perspective, the result is a standard Forge app: JavaScript code, manifest, resources, scopes, and deployment artifacts that run inside Atlassian’s infrastructure. From your perspective, it feels like you described the solution in English and got a working app in Jira that you can iterate on.

Why this no‑code path is so useful for Jira users

Under normal circumstances, Custom UI means React, bundlers, state management, styling, and strict iframe security rules. An AI Apps Builder hides that complexity and applies Forge best practices for you:

• ​It chooses reasonable layout and state patterns so you do not have to learn React from scratch.
• It ensures that all Jira and external API access goes through the Forge backend and @forge/api, with the right scopes and permission checks.

This lets Jira admins, project managers, team leads, and power users:

1. Quickly prototype issue panels, project dashboards, checklists, and custom reports by iterating on prompts instead of tickets and specs.
2. ​Adjust apps by talking to the AI (for example, “add a status filter” or “show only my team’s projects”) rather than editing code.
3. Hand off successful apps to developers later for performance or complex integrations, using the generated code as a starting point rather than rebuilding from zero.

Developers still benefit because AI can generate the first Forge app—modules, manifest, plumbing, and basic UI—leaving engineers free to focus on hard problems. Since the result is a regular Forge project, it fits into existing repos, code review processes, and security checks.
​

Code + UI Kit vs AI Apps Builder: a quick decision table

Question	Code + UI Kit	AI Apps Builder (Custom UI + LLM)
How fast can we get a first working app?	After learning Forge basics and JavaScript, simple apps take days and larger apps take weeks.	Often within minutes: describe the panel, dashboard, or page you want and let the agent generate a deployable app.
Do we need to code?	Yes. You need JS, Forge modules, manifests, scopes, and a willingness to handle UI Kit migrations.	Not for initial versions: you work in prompts, but you can still download and edit the generated code if needed.
How stable is the UI over time?	Strongly tied to Atlassian’s design system; UI Kit components can change appearance or APIs, requiring refactors and major app updates.	Uses Custom UI, giving more control over layout and styling; still subject to Forge changes, but less exposed to UI Kit-specific visual changes.
Who is this best for?	Teams with developer capacity that want maximum control and are comfortable maintaining code and handling platform changes.	Power Jira users and teams with limited developer time who need internal tools quickly and want to iterate from real usage.
How does it behave in Jira?	As a standard Forge app using UI Kit, running in an iframe with resolver-based backend logic, scopes, and auditability.	As a standard Forge app generated by the AI, with Custom UI, resolvers, scopes, and deployment all within Atlassian’s Forge model.

Which option should you choose?

Code + UI Kit makes the most sense when:

• You have developers available and you want full control over behaviour, performance, and long‑term architecture.
• ​You expect to iterate on the app for years and prefer to keep everything in your normal codebase, CI/CD, and review process.
• You are comfortable planning for UI Kit and design‑system changes, including refactors and permission updates.

An AI Apps Builder is the better starting point when:

• You need a working solution fast, from first idea to something Jira users can click on.
• You are a Jira admin or PM who does not have time to learn Forge or to wait for a full dev cycle.
• You want deployment to be easy, but also want the option to hand the generated code to developers later for hardening or extension.

​If your main constraint is time, Forge’s complexity, or limited developer capacity, an AI Apps Builder lets you turn “we wish Jira could…” into a real app by having a simple conversation.