DEV Community: Anisha Malde

Building High Quality Streaming Apps: The Blueprint

Anisha Malde — Fri, 24 Jul 2026 08:35:00 +0000

When viewers open a streaming app on Amazon Fire TV, they expect it to start quickly, be easy to navigate with a remote, and begin playback reliably. In a living-room environment, quality issues are visible immediately. If the app is slow, confusing, or unreliable, viewers may lose patience and leave, even when the content itself is strong.

Why teams need the same quality view

This post introduces the Fire TV Streaming App Quality Blueprint, a six-part series of posts for partner and app teams responsible for streaming experiences on Fire TV. Each post will cover what teams should have in place, why it matters for viewers and for the teams responsible for the app, and the questions teams and leaders should ask during quality reviews. It is written for the person accountable for the overall quality of a streaming app on Fire TV; whether that is an engineering leader, product leader, TPM, or engineer. For the rest of this series, we call this person / team the quality owners.

Each post is meant to help teams look at the same app experience together. Where is it working? Where does risk remain? What needs attention before the next release? The goal is to move those conversations earlier in the full lifecycle of the streaming app experience, so quality is considered during planning, design, development, testing, release, and operations. If quality is treated mainly as a final test or launch-readiness check, teams may find important issues too late, when fixes are harder, release options are limited, and viewers are more likely to experience problems in production.

Streaming app quality is not only about the app code, and it rarely sits with one team. On Fire TV, the app experience depends on many parts working together: the app, catalog, sign-in, subscriptions, playback, ads, third-party integrations, monitoring, release readiness, and support. When an issue occurs, viewers do not see the ownership map behind it. They see missing content, a slow app, buffering, repeated ads, or paid content that stays locked. Internally, the cause may sit with a different system, team, or even organization. One team may be looking at crash reports, another at playback errors, another at support contacts or partner-side metrics. If those signals are reviewed separately, the team can spend too much time debating the symptom and too little time deciding what needs to change before the next release.

The Blueprint gives teams a practical way to review the areas that most affect the Fire TV streaming app experience. It also pushes the review beyond individual defects, toward ownership, signals, and release practices.

How this relates to implementation guidance

This series is not a how-to coding guide, SDK (Software Development Kit) manual, or replacement for implementation documentation. For implementation guidance, teams should continue to use Fire TV and Appstore documentation, SDK guides, sample code, and Fire OS or React Native guidance where applicable. This series is about the quality question behind the implementation work: does the app experience meet the expectations viewers have on Fire TV? Is it easy to use, reliable during playback, stable in production, supported by useful signals, and safe to release?

The six pillars

The Blueprint is organized around six pillars. Each pillar focuses on a part of the viewer experience or the operating model behind it. Although the posts are written to stand alone, the pillars are ordered by dependency. You need visibility into what's happening before you can improve performance, you need stability before the experience feels polished, and you need operational maturity before you can ship with confidence:

Insight and Telemetry: Can the team see how the app is performing for viewers, where problems are happening, and which issues changed after a release? This includes app health, playback quality, errors, key viewer journeys, and release impact.
Performance and Efficiency: Startup time, remote responsiveness, how smooth browsing feels, screen loading, and device resource usage. What feels fine during development may feel sluggish on older Fire TV hardware in a real living room. This pillar focuses on whether the app feels fast enough for viewers, not whether it passes internal performance gates.
Stability and Resilience: Viewers don't think in terms of root cause. The app stopped working, and that's the whole story. This pillar covers crashes, ANRs (Application Not Responding), frozen screens, bad error handling, service outages, and network interruptions. If the team has known crash scenarios or unrecoverable states that haven't been prioritized, this is where that shows up.
Living-Room Experience and Accessibility: This is the difference between an app designed for a TV and one ported from mobile that technically runs. Remote navigation, focus behavior, Back button predictability, TV-appropriate layouts, voice support, accessibility. Most of these issues get caught late because teams test on desktop or emulators first and only pick up a real remote closer to launch.
Streaming Experience: Does video start, keep playing, and recover when something goes wrong? Covers on-demand and live content, ad insertion where applicable, mid-stream errors, and resume. Many of the "app is broken" reports from viewers are actually playback-path failures that cross multiple service boundaries.
Release and Operations Excellence: Can the team ship with confidence, catch regressions in production quickly, roll back without a fire drill, and learn from incidents before the next release? This pillar is less about code and more about the release practices and operational readiness around it.

What’s next

In our work with partner app teams on Fire TV, one of the hardest questions to answer cleanly is: which issue is hurting the most viewers right now? The next post is about building that answer. We start with Insight and Telemetry because teams need to see how the app is performing for viewers before they can improve it. It looks at app health and playback quality in production, how to identify the issues affecting viewers, and how to decide what to fix first.

Building a Dev Content Strategy that survives Monday

Anisha Malde — Wed, 22 Jul 2026 15:18:10 +0000

With AI making it easier than ever to publish anything we're all drowning in content and a lot of the time it's noise. Additionally, developers, more than most audiences, can smell 'slop' a mile away, and once you've lost their trust, you don't win it back with a louder headline. So our job in DevRel isn't to add to the pile. It's to earn enough trust that when we do publish, developers actually stop and read. Which leaves the question:

How do we build a content strategy that earns developers' trust?

That's exactly what I had to ask myself when I took over the developer content strategy for my Developer Advocacy team at Amazon. And as the saying goes, nothing good in life is easy 😂. It wasn't just about writing quality content. The issue was that our developer audience is enormous: multiple Appstores (Amazon Appstore, Ring Appstore, Alexa Appstore), two Operating Systems (Fire OS and Vega), and a growing set of form factors (Fire TV, Fire Tablet, Echo Show, Ring, Bee). Now combine that with the fact that each one of those surfaces comes with its own SDK releases, platform quirks, and tsunami of inbound content ideas: product teams wanting help with launches, developers dropping feedback, marketing needs for newsletters. Not to forget keeping on top of the latest trending AI tooling we need to weave in.

Overwhelmed was an understatement!

Honestly, my first thought was: is it too late to become a farmer? 😅 Jokes aside, I needed a way to sort out the mess, so I started with a few questions:

Where do the ideas come from?
What kinds of content can we make?
Who is each piece for?
And finally, how do we decide what to prioritise?

Step 1: Get all the ideas on the table

Before deciding what to make, we needed to know what content themes we had. And by theme I mean an idea or topic, not a finished piece of content yet, something like Improve performance on Vega or getting started with our MCP server. So I started by collating where those themes come from. Every theme in our backlog has to trace back to at least one of these sources:

Voice of the Developer. What are developers actually telling us? Forum posts, GitHub issues, event conversations, survey data, DMs. Not what we assume they want.
Goals. What are we trying to achieve as a team and as an org? If a piece of content doesn't ladder up to something we've committed to, it's worth de-prioritising.
Go To Market. What's launching? New devices, SDK releases, Appstore APIs. If product is shipping something, developers will need help using it and we need to plan for it.
Walk the product. What did we find when we built with it ourselves? Friction we hit before it becomes a developer pain point is important to mitigate.
Our own experience. What do we think developers need, based on years of doing this? This one's the most subjective and the easiest to over-index on, so we treat it as one voice among five, and never the loudest one in the room.

With the sources named, I can look at any sprint's backlog and quickly check we're covering the ground. If any of those sources are quiet, that's worth a conversation before we create anything else.

Step 2: Pick the right format for each idea

Once we had a list of themes, the next call was to figure out what shape each one should take. This is where teams usually reach for their favourite format by default (we're a video team, we like blogs, someone loves workshops), and I wanted to stop doing that.

So the first thing I did was write down every format we can make, roughly how long each takes, where it gets published, and who it's really for.

With every format on the table, picking one for a given theme becomes a judgement call, but not a random one. Here's the rough rule of thumb I use:

If it's visual, show it → Video. Anything with a UI, a device interaction, or a screen / IDE flow defaults to a video tutorial or a livestream / office hours. A tutorial telling someone to "press left, then OK, then wait for the next generic screen" is fighting the medium.
If it's a series of decisions, write it → Written. Architecture choices, trade-offs, and "why this and not that" pieces belong in a technical article or a thought leadership article. Readers can scan, jump around, and make informed decisions.
If they need to build it, make it hands-on → Hands-On. When the payoff is "developer has a running thing on their machine", this becomes a code lab, a sample app, or a boilerplate / template. Written explanation on its own doesn't cut it. In-person versions of this become workshops.
If AI is doing the work, make it AI-shaped → AI. If the developer is going to be pair-programming with Claude or Kiro to solve this, the content has to fit inside that workflow. This is where agent skills, prompt libraries, MCP server configurations, and AI-embedded 'tutorials' earn their spot.
If it's a moment, make it a moment → Written + Social. Launches, milestones, community wins, big learnings. Blog posts on developer.amazon.com, case studies / spotlights, and social content on LinkedIn and dev.to. Optimised for reach and timing, not depth.

None of these are hard rules. Plenty of themes get more than one format (a launch might get a blog, a video, and a sample app), but the rule of thumb makes the first format choice feel less arbitrary, and it forces us to justify when we depart from it.

Now we know what the theme is, and what shape it'll take. The last question was where in the developer's journey it belongs, because this is how we decide where to target activation.

Step 3: Map each idea to a stage of the developer journey

Every developer moves through roughly the same stages when they land on a new platform. They discover it, evaluate whether it fits, actually build something with it, and (hopefully) ship, grow, and monetise. If all our content lives at the "discover" end, developers get excited and then bounce because there's nothing to help them build. If it all lives at the "build" end, no one finds us in the first place.

So we tag every theme with the stage it activates. It's not a strict rule, more of a sanity check. When we're staring at a quarter's worth of ideas, we ask: is this balanced across the journey? Or are we accidentally shipping five discover-stage pieces and nothing that helps someone actually ship?

How we decide what to create

Once every theme has a source, a format, and an activation stage, deciding what to prioritise stops being a vibes exercise. What we're left with is a well-curated backlog with a good spread across sources, formats, and journey stages, a lot less overwhelming than the pile I started with. And when a new idea lands, it goes through the same three passes. Anything that clears all three joins the backlog and gets assigned out during sprints. But ultimately it gives me an answer I can back for every stakeholder in the room - product, marketing, my team, and the developers themselves 💛.

And on the note of Voice of the Developer, if there's anything you've been hoping we'd cover on Amazon devices, drop it in the comments and I'll add it to the backlog 😉.

Agents & Agent Orchestration, MCP, Skills, Context, Prompt & Harness Engineering 🤯: What, When, Where, How?

Anisha Malde — Mon, 29 Jun 2026 11:41:36 +0000

If you are like me, you are overwhelmed 🤯.

The way we build software has always shifted, and as engineers we have always had to keep up with new trends and ways of building. But historically it was one framework or tool at a time. I remember when React moved from class components to functional components and hooks back in 2019, I had time to learn it, blog about it, and read twitter fights over it.

Now it feels like we are on an exponential learning curve. New ways of building show up faster than I can finish reading the announcement post for the last one. So if you have not been living under a rock 😉 and you are still employed 😅 in tech, you have probably lived through the same 'vocabulary' creep as I have.

This is my attempt to lay out my learning journey in one place: what each of these terms mean, when they came about, how they all fit together, and where to find them in the tools you already use.

The What & When

Prompt engineering: refining intent

Most of our early interactions with LLMs started with "Hi, could you maybe review this for me, preeettty please?". But soon we realised we could get a better output by tweaking the words we prompted in, e.g. "You are a senior engineer reviewing this code, think critically and write tests", and so the practice of prompt engineering came about.

AWS calls it "the process where you guide generative AI solutions to generate desired outputs. In prompt engineering, you choose the most appropriate formats, phrases, words, and symbols that guide the AI to interact with your users more meaningfully." It includes techniques like prompt chaining and chain-of-thought tricks ("let's think step by step"). And it worked fine because models were small and tasks were short.

Context engineering: managing information

Eventually we realised the prompt alone wasn't cutting it, the model also needed 'context' to answer well. So the question stopped being "what is the perfect prompt?" and became "what is the perfect set of things in the context window right now?", and the practice of context engineering came about. The prompt is still in there but now you're managing what the model knows at the moment of the call, not just what you prompt it. But with limited tokens in a context window, it was also about making sure you don't overload it (avoiding context bloat). So really, context engineering is about managing a few categories of inputs and each one gave us a new bit of vocabulary:

Prompt: which we already know - the instructions, the role, the rules of how the model should behave, and the actual question being asked.
Knowledge (RAG, Retrieval-Augmented Generation): pulling relevant context from external sources (documents, databases, APIs, search indexes) into the window so the model can ground its answer in real data.
Memory: state that persists across conversations or sessions, both short-term (this conversation) and long-term (across sessions), plus context compression so older messages get summarised when things start to get long.
Tools: how the model talks to the outside world. MCP (Model Context Protocol) is the open standard for connecting models to external data, tools, and workflows.
Agent Skills: As context engineering matured, people realised they were re-loading the same combinations of the above (instructions, knowledge, and tools) over and over. Agent Skills appeared as an open standard to bundle them, originally developed by Anthropic, now adopted across Claude, Codex, Cursor, Gemini CLI, GitHub Copilot and many more. A Skill is a folder of instructions, knowledge, and tool wiring that the agent loads only when relevant, so the context window doesn't get bloated.

Now, agents as a concept aren't new, AI agents have existed for decades, chess engines, rule-based systems, reinforcement learning models. But what changed recently is that LLMs gave agents a reasoning engine, and context engineering gave them the domain knowledge and tools to actually do specific things well, and that's when agents became 'mainstream'.

Agents & Agent Orchestration

You can think of an agent as having an identity (its role and instructions), domain knowledge (the context, skills, memory it carries), tools (what it can call), and a loop that ties it all together. The loop is the cycle the agent runs through on every step: read the current context, reason about what to do next, call a tool, observe the result, and decide whether to keep going or stop. Without that loop, you've got a model that answers a question. With it, you've got something that can take multiple steps to get a job done. Now you might have already taken it a step further and have one agent that plans, another that implements, a third reviews. This is agent orchestration: the choreography between agents. But orchestration also answers who runs first, who runs in parallel, how the planner hands off, whether sub-agents share context, what happens when one fails. Common patterns include: fan-out to specialists, judge-and-vote, pipeline stages, planner-worker.

You could orchestrate agents before harness engineering had a name, but orchestration on its own is just word-based instructions, you tell the agents what to do and let them go. Agents would route dynamically, hand off silently, and hallucinate. So even though orchestration 'works', there's a deeper discipline that determines whether your agents actually succeed with the intended output, and that's where the term harness engineering came about.

Harness engineering: controlling execution

Harness engineering is the scaffolding around your agents, how context gets delivered, how outputs get verified, how plans get captured, and where & when humans can intervene. Orchestration decides what the agents do, the harness decides whether they can actually do it. As OpenAI puts it, the harness is the systems, scaffolding, and leverage that turn a model into something that can do real work.

Think of agents on their own like an engineering team told to "just build a checkout page". You've got a frontend dev, a backend dev, QA, a UX designer, all capable, all specialised. But without the scaffolding around them, here's what actually happens: nobody agrees on what "done" looks like (no task lifecycle), so the frontend builds against last week's API spec while the backend ships a new one (no shared context delivery). QA tests the happy path but never sees the designer's edge cases (no feedback loop). The backend dev pushes straight to prod on a Friday because nobody set up a staging gate (no guardrails). When it breaks, there's no rollback and no logs to tell you why (no state persistence, no observability). It's the same capable people doing the work, just with a completely different outcome.

Swap the engineering team for AI agents and you get the same failure modes, plus one more: the model itself is non-deterministic, the same prompt can take five different paths on five different runs. The harness is what holds it all together, the difference between an agent that might do the right thing and a system that reliably does. Concretely, it looks like:

Context delivery: assembling and delivering the prompt, knowledge, memory, tools, skills on every loop
Agent Orchestration: routing between specialised agents (each with its own role, tools, and skills), hand-offs, fan-out, judge-and-vote, planner-worker patterns, plus spawning sub-agents with their own isolation, lifecycle, and context
Feedback loops: act → observe → react → repeat. Plus the type checkers, linters, tests, and tool outputs that tell the agent when it has gone wrong, so it can self-correct
Task lifecycle: the macro-loop a run goes through, e.g. Triage → Clarify → Plan → Execute (TDD) → Evaluate → Done. The harness decides when each step starts and ends, and when to ask a human
Tool execution: retries, timeouts, fallbacks when something hangs or fails
Guardrails and sandboxing: read-only credentials, approval gates for destructive actions, content/output filters, filesystem isolation, the rules that keep the agent inside the lines
State persistence and recovery: memory, plans, transcripts, git checkpoints so the agent can be paused, resumed, or rolled back
Observability: traces, costs, evals, replay, the audit trail that makes the system legible to a human

How: it all fits together

So we understand harness engineering conceptually, but what does a real run look like end-to-end? The harness drives the agent through a specific task lifecycle, and it owns the arrows between every step. Here's one example:

Each step is owned by a different specialised agent, and the harness is what hands work from one to the next:

Router triages the incoming request, what kind of task is this, which lifecycle should it run, does it even have enough information to start?
Planner breaks the task into steps, surfaces assumptions, and writes a plan the next agent can execute against.
Generator does the actual work, ideally test-first, so the feedback loop has something to push back on.
Evaluator grades the output against the plan, the tests, and any acceptance criteria, and sends it back if it doesn't pass.
Verifier does the final end-to-end check, often by actually exercising the running app (Playwright, a real API call, a real build).
Human can intervene at any step, approving risky actions, correcting course, or kicking the run back to an earlier phase.

The harness owns the connective tissue between agents, what context gets passed along, when to retry, when to escalate, and when to call it done. It also owns the trace, a recording of every prompt and tool call that ran, which matters more than it sounds. With normal software you can read the code and predict what it does, but with an agent you can't, the same loop will take different paths on different runs, and the only way to understand what actually happened (and improve next time) is to read back the trace. That's the bit most people skip, and it's the reason "human in the loop" ends up being less of a checkbox and more of an ongoing job: you're watching runs in real time, stepping in when something goes off, approving the risky calls, auditing weird traces afterwards, and feeding the worst ones back as evals.

Tactics for making it work

The next question is how you actually make it work in practice, and here the field is converging on a handful of patterns:

Keep the harness thin, push the smarts into skills. A good harness is mostly plumbing, roughly 200 lines that run the loop, manage files, handle context, and keep things safe. The actual knowledge lives in skills. That way you can swap the model out without rewriting your skills, and you avoid the trap of building a brittle wrapper that has to know everything itself. (Garry Tan, "Thin Harness, Fat Skills")

Separate the agent doing the work from the agent grading it. Agents are reliably bad at marking their own homework, they will write code, declare it correct, and move on without ever questioning the result. A standalone evaluator with a sceptical streak is far easier to tune than a generator trying to critique itself, which is why this pattern shows up in nearly every harness writeup, often under the name evaluator-optimizer. (Anthropic, "Building Effective Agents")

One task per session, and check the baseline first. Each run should start with fresh context and a quick verification that the build, tests, and setup are still green before the agent touches anything. Without that baseline check, the agent will spend an hour debugging a problem that was already there when it sat down, and those compounding bugs across sessions are one of the easiest ways for a run to go sideways. (Simon Willison, "Designing Agentic Loops")

Stop prompting, start designing the loop. Once the lifecycle is set up, you stop typing one-off prompts and start shaping the loop that prompts on your behalf, with each agent getting its prompt assembled from the goal, the current context, and whatever the previous agent left behind. As Boris Cherny, head of Claude Code at Anthropic, put it: "I don't prompt Claude anymore. I have loops running that prompt Claude." (Addy Osmani, Loop Engineering)

Wire in fast feedback. Type checkers, linters, tests, and tools like Puppeteer or Playwright for anything UI-driven are what stop an agent from marking features done without ever running the thing. As Simon Willison puts it, automated tests "hugely amplify what these agents can do", because they give the loop something objective to check against. The feedback loop has to turn fast as well, because slow checks just mean fewer iterations before the context window runs out. (Simon Willison, "Designing Agentic Loops")

Strip the harness as the models get better. Every component in your harness is encoding an assumption about what the model can't do on its own, and those assumptions go stale faster than you'd think. With each model upgrade, pull one piece out and see whether anything actually breaks, because the best harness is the smallest one that still gets you to a reliable result. (OpenAI on harness engineering)

Where: tools for building your harness

So we've got the concepts, where do you actually start? It depends on how much you want to build yourself, and there are roughly three layers to choose from:

Use a ready-made harness. Someone else has already wired up the loop, the tools, the lifecycle, and the guardrails. You bring your model and configure it for your use case.
Build your own with an SDK. The SDK gives you the loop, tools, memory, and orchestration. You build the lifecycle, feedback loops, and guardrails on top.
Host it somewhere. Once it works locally, you need a runtime with memory, auth, observability, and scaling.

Most people start at layer 1 to see what good looks like, then drop to layer 2 when their use case stops fitting.

Layer 1: ready-made harnesses (mostly for coding tasks)

The most mature ready-made harnesses today are all coding agents. The use case is well-understood (read code, edit code, run tests, commit), and several of them are open enough that you can study how they're put together:

Claude Code — the closed-source benchmark. Automatic context engineering and compaction. Built on top of the Claude Agent SDK, which Anthropic publishes separately if you want to build your own version of it.
Cline — open-source agent runtime that runs as a CLI, IDE extension, or via SDK. Its harness is exposed as user-facing toggles: explicit Plan and Act modes for the lifecycle, step-level approval as the guardrail, .clinerules files for skills, MCP for tools, and checkpoints with one-click undo for state.
Pi — deliberately minimal. Six tools by default, everything else as configurable extensions. The cleanest one to read end-to-end.
Goose — the most general-purpose of the bunch, useful beyond coding. YAML recipes as portable lifecycles, MCP for tools, subagents for orchestration, and an adversary reviewer as a guardrail.

If your use case is also coding, you may not need to leave this layer at all, fork one, drop your skills and rules in, and you're done.

Layer 2: build your own with an SDK

Once you step outside coding (customer support, document processing, a TV-app generator, anything domain-specific), the ready-made harnesses stop fitting. That's when you drop down to an SDK.

An SDK is basically a half-built harness. It ships you the engine, the agent loop, tool execution via MCP, memory, orchestration primitives, observability hooks, and you finish the rest, the lifecycle phases, the skills, the verify rules, the domain logic. Claude Code is what Anthropic built on top of the Claude Agent SDK. You'd be doing the same thing, just for your problem.

A real example: tv-build-harness, by @giolaq, generates multi-platform TV apps from a JSON manifest. Under the hood it runs the Claude CLI (or Strands SDK) as the engine, and on top the author built a deterministic pipeline of phases (plan → scaffold → branding → content → screens → ... → visual_qa_loop), each loading targeted skills, each verified before moving on, each git-committed so the run can be paused or resumed. "Thin harness, fat skills" in practice. That's what Layer 2 looks like, the SDK gives you the loop, you give it the structure your problem needs.

The SDKs themselves split two ways:

Model-aligned (tighter integration, locked to one model family): Claude Agent SDK, OpenAI Agents SDK (the production successor to Swarm), Google ADK (multi-language, model-agnostic via LiteLLM), and Microsoft Agent Framework (the direct successor to AutoGen and Semantic Kernel).

Provider-agnostic (swap models freely, more setup): LangGraph for graph-based workflows, Strands Agents (AWS, open source) for a model-driven thin loop, Vercel AI SDK as the TypeScript default (v7 even ships a HarnessAgent primitive), Eve (also Vercel, in beta) as a filesystem-first framework where you author the agent by dropping files into tools/, skills/, and channels/ folders, Mastra for TypeScript with workflows, memory, evals, and RAG built in, and CrewAI for role-based agent 'crews'.

Whichever SDK you pick, what your harness ends up looking like depends largely on the task. A coding agent leans on sandboxed execution, git, and a test runner. A customer support agent leans on memory, RAG, and approval gates. A TV-app generator (like the one above) leans on visual QA loops and platform-specific verify rules. Same building blocks, very different assemblies, because the failure modes you're guarding against are different.

Layer 3: host it somewhere

Once your harness works locally, you need somewhere to run it with memory, auth, observability, and scaling.

Amazon Bedrock AgentCore: managed runtime, memory, identity, gateway, observability. Framework-agnostic, supports Strands, LangChain, OpenAI Agents SDK, and the Claude Agent SDK.
LangSmith Deployment (renamed from LangGraph Platform): the default if you're on LangGraph.
OpenAI AgentKit: Agent Builder, ChatKit, and hosted tools via the Responses API.
Self-hosted on Fargate (long loops), Modal (sandboxed compute), or Lambda (short loops only).

The cross-cutting bits

Whichever layers you pick, you'll also need:

Tools: MCP servers and the new official registry. MCP was donated to the Linux Foundation in December 2025, so it's the safest bet for portable tool integration.
State and rollback: Git. Every coding harness uses it for a reason.
Feedback loops: your test suite, type checker, and linter. Without these, the agent has nothing objective to push back against.
Observability: Langfuse, LangSmith, Arize Phoenix, or Braintrust for traces and evals. The OpenTelemetry GenAI conventions are still in development, so don't assume your tracing is portable yet.

Conclusion

Hopefully you're feeling slightly less overwhelmed. At the end of the day, this is all just tactics for getting the model to do what we actually want: reliably, repeatedly, and without burning down the building. The prompt was the first lever, and everything since (context, skills, agents, orchestration, the whole harness) is the same instinct, shape what the model does so the outcome is something you can ship.

So while the vocabulary will keep changing, the underlying problem we are trying to solve won't. It just depends on how you want to get there, start with what the model gives you out of the box, and add layers only when you hit their limits.

To Share or Not to Share: Building for multi-platform

Anisha Malde — Tue, 14 Apr 2026 13:06:56 +0000

"To share, or not to share, that is the question." - Shakespeare, if he'd been a React Native developer"

If you build apps with React Native, you've definitely asked yourself this ☝️. You've got navigation, state management, business logic, UI components, most of it is the same, and is probably using the same libraries, regardless of whether you're targeting Android TV, Apple TV, or Fire TV. So why maintain separate codebases?

With Vega OS, we had a chance to get this right from the start. Rather than shipping another platform that locks you into a single target, we wanted to make it easy to build for multiple TV platforms at the same time. Depending on your app's architecture, you can realistically share 70-85% of your codebase across TV operating systems. I want to walk you through how it works, and help you figure out what 'to share or not to share'.

To help, we've published a few projects on Github. You can pick the one that fits your workflow and start your journey, or read on and I'll walk through the workspace setup, some of the tooling that makes it all work and what code you can share today (and what you shouldn't).

👋 Multi-TV Hello World - starter template
📺 React Native Multi-TV App Sample - production-ready reference app
🤖 Vega Multi-TV Migration agent skill - AI assisted migration

The shared workspace approach

So what does sharing code across TV platforms actually look like in practice? You want a setup where the shared code lives in one place and the OS specific features (video playback, native integrations, platform quirks) stay isolated.

To set this up, we refactor the Vega project into a monorepo using Yarn v4 workspaces. On the Vega side, you keep using the Vega SDK as normal. For the other platforms, we use Expo TV, which gives you Android TV, Apple TV, and Web support out of the box with a single Expo project. You split things into three workspaces:

packages/shared/ - OS-agnostic code (the majority of your app)
packages/vega/ - Vega-specific code for Fire TV
packages/expotv/ - Expo TV for Android TV, Apple TV, and Web

A root package.json coordinates builds across these sub projects. Each workspace has its own dependencies and build configuration, but they share common code through workspace imports.

my-app/
├── package.json                  # Root workspace config (Yarn 4.x)
├── packages/
│   ├── shared/                   # @myapp/shared - OS agnostic code
│   │   ├── package.json
│   │   ├── index.ts
│   │   └── src/
│   │       ├── components/       # Shared UI (Banner.tsx, Banner.kepler.tsx, Banner.android.tsx)
│   │       ├── hooks/
│   │       ├── services/
│   │       └── utils/
│   ├── vega/                     # @myapp/vega - Fire TV
│   │   ├── src/App.tsx
│   │   ├── manifest.toml
│   │   └── metro.config.js
│   └── expotv/                   # @myapp/expotv - Android TV / Apple TV / Web
│       ├── src/App.tsx
│       ├── app.json
│       └── metro.config.js

The key rule to remember is OS packages import from shared, but shared never imports from OS packages.

Note: By default, the Vega SDK works with npm, but this monorepo approach uses Yarn v4 workspaces.

The tooling that makes sharing work

The workspace structure gets you most of the way there, but two pieces of tooling tie it all together.

The first is VMRP (Vega Module Resolver Preset). Your shared code uses standard React Native imports like react-native-gesture-handler or react-native-reanimated, but Vega has its own ported versions of these libraries. VMRP is a Babel preset that automatically swaps those imports for their Vega equivalents at build time, so your shared code stays clean and portable.

You configure it in your Vega package's babel.config.js:

// packages/vega/babel.config.js
module.exports = {
  presets: [
    'module:metro-react-native-babel-preset',
    'module:@amazon-devices/kepler-module-resolver-preset',
  ],
};

With this in place, from 'react-native-gesture-handler' in your shared code automatically resolves to @amazon-devices/react-native-gesture-handler when building for Vega. No conditional imports, no platform checks.

The second is Vega Studio's monorepo support. It automatically detects your workspace layout and imports Vega sub packages when you open the project. Enable it in Settings > Vega > Features: Monorepo, and it handles package discovery, workspace synchronisation, and build task coordination for you.

Now lets discuss:

What makes sense to share

Not all code belongs in packages/shared/. Some things work identically across platforms, some need OS-specific implementations, and some sit in between. Here's how to think about what goes where.

Business logic and state management (share it)

This is the easiest win and where you get the most reuse. Your API calls, Redux/Zustand stores, data transformations, validation logic, formatting utilities usually don't have any OS specific dependencies. As a rule of thumb, if it doesn't touch a native API or render anything to screen, it belongs in packages/shared/.

The Multi-TV App Sample demonstrates this with its dynamic content loading. The catalog API client, data transforms, and type definitions all live in the shared package and every platform consumes the same data layer.

UI components (share most of it)

Most of your UI components are shareable too. Buttons, cards, lists, layouts, modals, grid views are usually standard React Native that works across platforms without changes.

Where it gets interesting is platform specific styling. React Native's file extension resolution handles this cleanly. Write your base component as Banner.tsx, then add platform specific extentions Banner.kepler.tsx. Metro picks the right file at build time (this relies on your Metro config being set up for monorepo resolution, both the Hello World and Multi-TV App Sample repos include this configuration).

The Hello World repo shows this pattern with its HeaderLogo component, which loads different platform logos using .kepler.tsx, .android.tsx, .ios.tsx, and .web.tsx variants.

You can also use Platform.select() for smaller differences that don't warrant separate files.

Navigation and screen flows (share with care)

There are two types of navigation patterns in TV apps, and they share differently.

Screen-to-screen routing (moving between pages, tabs, drawers) is usually fully shareable. If you're using React Navigation (which Vega supports via its react-navigation package), your screen definitions, route configs, and navigation structure work the same across platforms.

Spatial / Focus navigation (moving focus between elements on screen with a remote control d-pad) is where it gets platform-specific. The Multi-TV App Sample uses React TV Space Navigation to handle focus movement across all platforms, but the layer underneath that captures remote control key events differs per OS. The RemoteControlManager has separate .android.ts, .ios.ts, and .kepler.ts files because each platform fires different key events. The focus logic is shared, the input handling is forked.

Layout and theming (share the system, tweak per platform)

TV apps need to look right across different screen sizes and display densities. The pattern here is the same as with the UI: share the design system (tokens, spacing, typography scales), and use platform-specific files or Platform.select() where individual platforms need adjustments. For production apps, consider building out a proper theme layer with responsive layouts rather than relying on simple scaling alone.

The Hello World repo includes scaling utilities that normalise dimensions across TV displays based on a 1920x1080 baseline. The scaling logic itself is shared, but you might need platform-specific tweaks for things like safe areas or overscan.

What you should keep separate

Media Player

Production streaming apps tend to use OS-specific media players for optimal performance. You can either follow that path, using native implementations per OS, or use an abstraction to work across like react-native-video (which now has Vega support). Unless you use these abstractions, your media implementations should live in your OS-specific packages.

Amazon specific features

Content Launcher, In-App Purchase, Amazon Device Messaging, and similar features currently need separate implementations for Vega and Fire OS because their underlying APIs are OS-specific. We're working to migrate these behind single RN libraries, but for now, structure these implementations so they're easy to consolidate later. Keep them in your platform packages with clean interfaces that shared code can call through.

Vega UI Components (VUIC)

Worth flagging early, simple VUIC components like Button and Text migrate easily to standard React Native equivalents. But Carousel and SeekBar need more work to replace. Identify these dependencies during your analysis phase so you're not surprised mid-migration.

Native modules and DRM

Anything that touches native code directly (custom TurboModules, DRM implementations, hardware-specific features) stays platform-specific. No way around it.

Try it yourself: the Hello World starter

The fastest way to see this in action is the Multi-TV Hello World repo. It's a hello-world project with a shared Header component that renders across Vega, Android TV, Apple TV, and Web from the same codebase.

See it in production: the Multi-TV App Sample

For something thats closer to a production app, check out the React Native Multi-TV App Sample. This is a TV app template with:

Video playback via react-native-video
Spatial navigation with React TV Space Navigation
Drawer navigation, grid layouts, and a dynamic hero banner
Remote control support across all platforms
A shared UI library (@multi-tv/shared-ui) with platform-specific file resolution

It supports Android TV, Apple TV, Fire TV (Fire OS), Fire TV (Vega OS), and Web from a single monorepo. Good reference for how the shared workspace pattern holds up at scale.

Migrating your own app: the AI-assisted approach

We've also packaged our migration process into a three-phase agent skill that works with Kiro, Claude, or other AI coding assistants. It's available on GitHub: vega-multi-tv-migration.

To use it with Kiro, copy the vega-multi-tv-migration directory into ~/.kiro/skills/ and start a conversation about migrating your app. It activates automatically based on your conversation context.

Phase 1: Analyse your codebase

The skill runs static code analysis and gives you an executive summary with estimated code reuse percentage, a dependency classification (what goes to shared, what stays OS-specific, what VMRP handles), and a screen-by-screen migration plan.

"Analyse my Vega app for multi-platform migration."

Phase 2: Build the shared workspace structure

This creates the monorepo scaffold, moves code into shared and vega packages, configures Metro for monorepo resolution, and sets up VMRP. After this step, your Vega app should build and run exactly as before, but with shared code properly separated.

"Convert my Vega project to a yarn workspaces monorepo using the analysis from Phase 1."

Phase 3: Add OS-specific implementations

This sets up the Expo TV package and implements replacements for Vega-specific dependencies:

@amazon-devices/kepler-player-client becomes react-native-video
@amazon-devices/kepler-ui-components becomes custom components or community libraries
@amazon-devices/kepler-file-system becomes expo-file-system

"Add Android TV and Apple TV support using Expo TV. Replace my Vega-specific dependencies with stock React Native equivalents."

Best practices

A few things we've learned the hard way:

Clean up before migration: AI tools migrate code as is, including unused files and existing bugs - Do some optimisation first.
Manage React Native version deltas: Platforms don't need identical RN versions, but keep the delta to 4-6 versions max for third-party library compatibility.
Test on real devices: Emulators are great for development, but validate on real hardware before shipping. TV apps behave differently on actual TVs - shocking, I know 😱.
Prebuild targets separately first: Get each target running independently before building together to save you some debugging headache.

Get started building today:

Try the Multi-TV Hello World to see Fast Refresh across Vega, Android TV, Apple TV, and Web.
Explore the Multi-TV App Sample for a production-ready reference.
Run the migration agent skill on your own app.
Tell us what works, what doesn't, and what you'd like to see next- you can open a discussion on GitHub or in our Forums.

🎵 On the 12 Days of Christmas, Amazon Developer gave to me... 🎵

Anisha Malde — Thu, 15 Jan 2026 18:11:51 +0000

Made a New Year's resolution to learn something new? We've got you covered!

Back in December, our team turned the holidays into a developer advent calendar, unwrapping a different Amazon tool each day leading up to Christmas. We covered 12 different Amazon tools / services in 12 LinkedIn posts with real code snippets and working demos. Whether you're curious about AI voice generation or custom Kiro agent consider it your New Year's resolution starter pack for building with Amazon's developer.

So grab your coffeee, and let's see what Amazon Developer gave to theee 🎵

🎵 On the 1st day of Christmas 🎄, Amazon Developer gave to me… voice generation with Polly 🎵

by @anishamalde

Okay I’ll admit it, I also yell at Alexa, but I’ll also admit her voice is oddly comforting. So when I needed a voice for my AI assistant app, I turned to Amazon Polly. Polly is AWS’s text-to-speech service that turns text into audio with neural voices across 30+ languages, the same underlying tech that powers Alexa’s voice.

The setup was surprisingly simple. Polly handles all the heavy lifting, so with just a few lines of code

const result = await pollyClient.send(
  new SynthesizeSpeechCommand({
    OutputFormat: "mp3",
    Text: "Welcome!",
    VoiceId: "Matthew",
    Engine: "neural",
  })
);

I had my app 'talking' in different accents. The British version even wanted to banter with me 😂

Check out the demo here ⬇️

Amazon Polly Voice Generation for AI Assistants | Anisha Malde posted on the topic | LinkedIn

🎵 On the 1st day of Christmas 🎄, Amazon Developer gave to me… voice generation with Polly 🎵 Okay I’ll admit it, I also yell at Alexa, but I’ll also admit her voice is oddly comforting. So when I needed a voice for my AI assistant app, I turned to Amazon Polly (➡️ https://lnkd.in/d7kNn4UR). Polly is AWS’s text-to-speech service that turns text into audio with neural voices across 30+ languages, the same underlying tech that powers Alexa’s voice. The setup was surprisingly simple. Polly handles all the heavy lifting, so with just a few lines of code (➡️ https://lnkd.in/dJjKDT4H), I had my app 'talking' in different accents. The British version even wanted to banter with me 😂 ➕ Follow along as today is just Day 1 of our 𝟭𝟮 𝗗𝗮𝘆𝘀 𝗼𝗳 𝗔𝗺𝗮𝘇𝗼𝗻 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿 🎄 What would you build with Polly? Drop your ideas below 👇

linkedin.com

🎵 On the 2nd day of Christmas 🎄, Amazon Developer gave to me… Kiro power🎵

by @giolaq

In the hashtag AI Agents world Context overload is a problem! I love how Kiro approached this issue by using Kiro Powers

Now you might be asking, what is a Kiro Power? Think of it as Santa's list for your AI agent: it gives instant access to specialized knowledge, tools, and best practices for one technology (like multi-platform TV 📺 builds), loading it only when you need it for maximum efficiency and speed.

I put this power to the test, creating one and using it to successfully extend my VegaOS TV app (built in ReactNative) to other TV platforms. It automatically managed the complex, chilly build systems, leaving us with a warm, clean React Native code.

Check it out the demo here

#ai #kiro #vegaos #reactnative | Giovanni Laquidara

🎵 On the 2nd day of Christmas 🎄, Amazon Developer gave to me… Kiro power🎵 In the #AI Agents world Context overload is a problem! I love how #Kiro approached this issue by using Kiro Powers https://lnkd.in/e99fDAfR What is a Kiro Power? Think of it as Santa's list for your AI agent: it gives instant access to specialized knowledge, tools, and best practices for one technology (like multi-platform TV 📺 builds), loading it only when you need it for maximum efficiency and speed. I put this power to the test, creating one and using it to successfully extend my #VegaOS TV app (built in #ReactNative) to other TV platforms. It automatically managed the complex, chilly build systems, leaving us with a warm, clean React Native code. Check it out here : 👉 https://lnkd.in/eAHA3gha Day 2 of 12 Days of Amazon Developer 🎄

linkedin.com

🎵 On the 3rd day of Christmas, Amazon Developer gave to me… 3 CLI Custom Agents 🎵

by @trag

Every time I switch tasks, I used to re-explain my whole world to an agentic sidekick: My team structure. The acronyms. My writing style. Over and over. Blaaargggh!

AWS Developers' custom agents for Kiro CLI fixed that

A custom agent is a JSON config that defines:

Which tools the agent can access
What files/docs auto-load as context
A custom system prompt for the persona you need

I've set up a few for different modes:
trag – auto-loads my teammates, work glossary, and style guide
social-media-lead – writes channel-specific posts for LinkedIn, etc
pair-progammer – gets me the feedback I need while coding

Setup:
/agent generate

Swap anytime:
/agent swap

Now when I start a session, the agent already knows who I am and what I'm working on. No preamble. Just work.

Check out the demo here ⬇️

Amazon Developer CLI Custom Agents Simplify Workflows | Chris Traganos posted on the topic | LinkedIn

🎵 On the 3rd day of Christmas, Amazon Developer gave to me… 3 CLI Custom Agents 🎵 Every time I switch tasks, I used to re-explain my whole world to an agentic sidekick: My team structure. The acronyms. My writing style. Over and over. Blaaargggh! AWS Developers' custom agents for Kiro CLI fixed that (➡️ https://lnkd.in/d5zhHmbj) A custom agent is a JSON config that defines: • Which tools the agent can access • What files/docs auto-load as context • A custom system prompt for the persona you need I've set up a few for different modes: trag – auto-loads my teammates, work glossary, and style guide social-media-lead – writes channel-specific posts for LinkedIn, etc pair-progammer – gets me the feedback I need while coding Setup: `/agent generate` Swap anytime: `/agent swap` Now when I start a session, the agent already knows who I am and what I'm working on. No preamble. Just work. Follow along for more Amazon developer as today is just Day 3 of our 12 days of Amazon Developer 🎄

linkedin.com

🎵 On the 4th day of Christmas, Amazon Developer gave to me… Kiro CLI: https://kiro.dev/cli/

by @mosesroth

Everyone reading this has probably used an AI chatbot, but have you used one on the CLI? It’s a whole different ballgame.

Using an LLM on the CLI is a lot like using Chat GPT or Claude in your browser, but instead you chat with it directly from the terminal.

What’s so great about it is how convenient it is for vibe coding an app or testing one.

When I was testing React Native libraries on Fire OS, it made the process so much easier and faster. I would just give it the URL of the library and tell it to create an app and test it on a Fire device. That’s it, just one step. No need to manually create a new app, no need to download the repo myself or integrate it or copy-paste code from a browser-based LLM, and no need to set up adb or manually run the app. It took care of everything.

Whether you’re a veteran vibe-coder or thinking about dipping your toes into the water for the first time, check out Kiro CLI

🎵 On the 4th day of Christmas, Amazon Developer gave to me… Kiro CLI: https://kiro.dev/cli/ Everyone reading this has probably used an AI chatbot, but have you used one on the CLI (command-line… | Moses Roth

🎵 On the 4th day of Christmas, Amazon Developer gave to me… Kiro CLI: https://kiro.dev/cli/ Everyone reading this has probably used an AI chatbot, but have you used one on the CLI (command-line interface)? It’s a whole different ballgame. Using an LLM on the CLI is a lot like using Chat GPT or Claude in your browser, but instead you chat with it directly from the terminal. What’s so great about it is how convenient it is for vibe coding an app or testing one. When I was testing React Native libraries on Fire OS ( https://lnkd.in/ghvNFv-K ), it made the process so much easier and faster. I would just give it the URL of the library and tell it to create an app and test it on a Fire device. That’s it, just one step. No need to manually create a new app, no need to download the repo myself or integrate it or copy-paste code from a browser-based LLM, and no need to set up adb or manually run the app. It took care of everything. Whether you’re a veteran vibe-coder or thinking about dipping your toes into the water for the first time, check out Kiro CLI: https://kiro.dev/cli/

linkedin.com

🎵 On the 5th day of Christmas, Amazon Developer gave to me… Amazon Bedrock 🎵

by @knmeiss

Ever wondered what powers the AI behind Prime Video & Amazon MGM Studios's personalized recaps, Ring's smart video search or Alexa+'s conversational intelligence? Meet Amazon Bedrock

Bedrock is a fully managed service that makes leading foundation models from Amazon, Anthropic, AI21 Labs, and more accessible through a single API. This allows you to build and scale generative AI applications without managing infrastructure

🎬 Prime Video & Amazon MGM Studios uses Bedrock to power conversational and personalized interactions across tens of thousands of services and devices with agentic capabilities. X-Ray Recaps also uses Bedrock to understand storylines, emotions and character relationships.
🔔 Ring uses Bedrock for video understanding and search, making it easier to find specific moments and identify patterns in your footage.
🏀 Live Sports uses Bedrock to detect and capture slam dunks, three-pointers, and key plays in real-time, then generates instant highlight clips.
🗣️ Alexa+ uses Bedrock to route requests to specialized models for more natural conversations.
🛍️ Rufus uses Bedrock to combine multiple foundation models with Amazon's product knowledge, reviews, and Q&A data to deliver sub-second responses to millions of shoppers.

Ready to transform your AI journey? Start sleigh-ing your AI goals today with this rock-solid solution! 🪨🛷

Amazon Bedrock – Build genAI applications and agents at production scale – AWS | Kourtney M.

🎵 On the 5th day of Christmas, Amazon Developer gave to me… Amazon Bedrock 🎵 Ever wondered what powers the AI behind Prime Video & Amazon MGM Studios's personalized recaps, Ring's smart video search or Alexa+'s conversational intelligence? Meet Amazon Bedrock (➡️ https://lnkd.in/grzc8ptt)! Bedrock is a fully managed service that makes leading foundation models from Amazon, Anthropic, AI21 Labs, and more accessible through a single API. This allows you to build and scale generative AI applications without managing infrastructure 🎬 Prime Video & Amazon MGM Studios uses Bedrock (➡️https://lnkd.in/gEE_a99R) to power conversational and personalized interactions across tens of thousands of services and devices with agentic capabilities. X-Ray Recaps also uses Bedrock to understand storylines, emotions and character relationships. 🔔 Ring uses Bedrock (➡️ https://lnkd.in/gErQRQxS) for video understanding and search, making it easier to find specific moments and identify patterns in your footage. 🏀 Live Sports uses Bedrock (➡️ https://lnkd.in/gCDDC8CW) to detect and capture slam dunks, three-pointers, and key plays in real-time, then generates instant highlight clips. 🗣️ Alexa+ uses Bedrock (➡️ https://lnkd.in/gV494Sia) to route requests to specialized models for more natural conversations. 🛍️ Rufus uses Bedrock (➡️ https://lnkd.in/gQe-eqeN) to combine multiple foundation models with Amazon's product knowledge, reviews, and Q&A data to deliver sub-second responses to millions of shoppers. Ready to transform your AI journey? Start sleigh-ing your AI goals today with this rock-solid solution! 🪨🛷 ➕ Follow along as today is Day 5 of our 𝟭𝟮 𝗗𝗮𝘆𝘀 𝗼𝗳 Amazon Developer 🎄

linkedin.com

🎵 On the 6th day of Christmas 🎄, Amazon Developer gave to me… browser automation with Amazon Nova Act 🎵

by @emersonsklar

One of the most exciting things this year has been the shift from AI that just talks to AI that acts. Amazon Nova Act certainly knocks it out of the park; it's the AI agent service turning browsers into autonomous coworkers. If you’ve ever dreamed of “set it and forget it” automation for complex UI workflows, this is your new best friend. 👇

Nova Act lets developers build, deploy, and manage fleets of reliable AI agents for automating browser-based tasks at enterprise scale. And it’s trained specifically to act – not just chat – driving browsers, filling forms, and clicking buttons with >90% task reliability in production. Think of it as a “digital intern” for automating business processes that never gets distracted.

🔧 Why this matters:

Reliability at Scale: While most agentic tools struggle at ~50% accuracy, Nova Act achieves >90% success rates on tricky UI elements (date pickers, popups, dropdowns) thanks to reinforcement learning on 1000s of simulated web environments.
Speed to Value: Go from natural-language prototype → production in hours (not months). The new Nova Act Playground lets you refine workflows visually in minutes, while the Python SDK supports advanced deployments.
Native AWS Integration: Seamlessly ties into Amazon Bedrock, CloudWatch, and IAM. No “glue code” needed – just secure, scalable automation.
Multi-Agent Orchestration: Pair with Strands Agents framework to coordinate complex, cross-domain workflows (e.g., QA → data extraction → API calls).

🧪 See it in action: Here’s a simple script where Nova Act navigates to the Amazon.com website, looks for a board game, about everyone’s favorite Blue Heeler, ensures it can get here in time, and adds it to my cart!

🌍 How customers are winning:

QA Testing: Tyler Technologies cut test-suite creation time from weeks to minutes by converting manual test plans into automated scenarios with natural language prompts
Internal Tools: Amazon Leo uses Nova Act to validate 1000s of test cases across web/mobile for its upcoming satellite internet launch.

Amazon Nova Act Automates Browser Tasks with 90% Reliability | Emerson Sklar posted on the topic | LinkedIn

🎵 On the 6th day of Christmas 🎄, Amazon Developer gave to me… browser automation with Amazon Nova Act 🎵 One of the most exciting things this year hasn’t been another AI demo – it’s the shift from AI that just talks to AI that acts. Amazon Nova Act certainly knocks it out of the park; it's the AI agent service turning browsers into autonomous coworkers. If you’ve ever dreamed of “set it and forget it” automation for complex UI workflows, this is your new best friend. 👇 Nova Act lets developers build, deploy, and manage fleets of reliable AI agents for automating browser-based tasks at enterprise scale. And it’s trained specifically to act – not just chat – driving browsers, filling forms, and clicking buttons with >90% task reliability in production. Think of it as a “digital intern” for automating business processes that never gets distracted. 🔧 Why this matters: · Reliability at Scale: While most agentic tools struggle at ~50% accuracy, Nova Act achieves >90% success rates on tricky UI elements (date pickers, popups, dropdowns) thanks to reinforcement learning on 1000s of simulated web environments. · Speed to Value: Go from natural-language prototype → production in hours (not months). The new Nova Act Playground lets you refine workflows visually in minutes, while the Python SDK supports advanced deployments. · Native AWS Integration: Seamlessly ties into Amazon Bedrock, CloudWatch, and IAM. No “glue code” needed – just secure, scalable automation. · Multi-Agent Orchestration: Pair with Strands Agents framework to coordinate complex, cross-domain workflows (e.g., QA → data extraction → API calls). 🧪 See it in action: Christmas is coming up, and everybody needs a little help getting the last of the presents on Santa’s lists. Here’s a simple script (https://lnkd.in/g97HBuyq) where Nova Act navigates to the Amazon.com website, looks for a board game about everyone’s favorite Blue Heeler, ensures it can get here in time, and adds it to my cart 🌍 How customers are winning: · QA Testing: Tyler Technologies cut test-suite creation time from weeks to minutes by converting manual test plans into automated scenarios with natural language prompts. https://lnkd.in/g2gKxP-t · Internal Tools: Amazon Leo uses Nova Act to validate 1000s of test cases across web/mobile for its upcoming satellite internet launch. https://lnkd.in/gidrHN92 💬 Let’s Talk Automation! What repetitive browser tasks are you tired of doing manually? 🤔 👇 Comment below with your biggest automation headache – let’s brainstorm how Nova Act could solve it! 🔗 Dive deeper: Nova Act Home https://lnkd.in/gVzN59xk ➕ Follow along as today is Day 6 of our 𝟭𝟮 𝗗𝗮𝘆𝘀 𝗼𝗳 Amazon Developer 🎄 #AWS #AI #Developers #Automation #GenAI #AmazonNova #NovaAct

linkedin.com

🎵 On the 8th day of Christmas 🎄, Amazon Developer gave to me ... one prompt UI magic with Kiro ✏️ 📺 🎵

by giolaq

From idea → wireframe → UI → working app… it usually takes too many steps.

I love how Kiro changes this with a single simple prompt.

This time, I pushed it further:
👉 I gave Kiro one prompt and a simple pencil sketch…
👉 and asked it to turn that into a full 10-foot TV UI web app.

Kiro understood the TV navigation patterns (D-pad, focus states) and the 10-foot UI guidelines with a great TV layout 📺
And the code is available here

#kiro #kiro #kiro #aiagents #tvdevelopment #ux #uidesign #10footui #amazondeveloper #buildinpublic | Giovanni Laquidara

🎵 𝐎𝐧 𝐭𝐡𝐞 8𝐭𝐡 𝐝𝐚𝐲 𝐨𝐟 𝐂𝐡𝐫𝐢𝐬𝐭𝐦𝐚𝐬 🎄, Amazon Developer 𝐠𝐚𝐯𝐞 𝐭𝐨 𝐦𝐞… 𝐨𝐧𝐞 𝐩𝐫𝐨𝐦𝐩𝐭 𝐔𝐈 𝐦𝐚𝐠𝐢𝐜 𝐰𝐢𝐭𝐡 #𝐊𝐢𝐫𝐨 ✏️📺 🎵 From idea → wireframe → UI → working app… it usually takes too many steps. I love how #Kiro changes this with a single simple prompt. This time, I pushed it further: 👉 I gave Kiro one prompt and a simple pencil sketch… 👉 and asked it to turn that into a full 10-foot TV UI web app. Kiro understood the TV navigation patterns (D-pad, focus states) and the 10-foot UI guidelines with a great TV layout 📺 And the code is available here 👉 https://lnkd.in/eUFb9p5p Follow along for more Amazon Developer as today is just Day 8 of our 12 days of Amazon Developer 🎄 #Kiro #AIAgents #TVDevelopment #UX #UIDesign #10FootUI #AmazonDeveloper #BuildInPublic

linkedin.com

🎵 On the 9th day of Christmas, Amazon Developer gave to me… AWS Lightsail! 🎵

by trag

I need a secure cloud box to run Kiro CLI, Codex, Claude Code, and batch scripts without exposing my home network. Lightsail from Amazon Web Services (AWS) was able to get me up and running in minutes for under $5/month

Here's my workflow:

📱 iSH – SSH terminal for iOS
📂 Textastic – secure file transfer and SSH
☁️ Lightsail – my Ubuntu instance with an SSH alias as tragbox for quick access

I SSH in, run either kiro-cli / claude / codex depending on the project, and my custom agents are live from my phone. Plus, I have a few MCPs running including GitHub and Context7 for extended capabilities.

My top use cases:

Pull conference speaker data and build tables of mutual connections
Run batch image cleanup and CSV processing when I'm away from my laptop
Execute long-running scripts without tying up my local machine

Why Lightsail?
I considered EC2, Fargate, and other options but all too much setup for my use case. Lightsail gave me an Ubuntu box with a straightforward console, flat monthly pricing (no surprise bills), and I can bump RAM or storage when I need it. It's firewalled away from my home network, so I'm not worried about exposing internal endpoints.

It really just works - I spin up agents on demand, run what I need, and move on.

Check out the demo here ⬇️

🎵 On the 9th day of Christmas, Amazon Developer gave to me… AWS Lightsail! 🎵 I need a secure cloud box to run Kiro CLI, Codex, Claude Code, and batch scripts without exposing my home network… | Chris Traganos

🎵 On the 9th day of Christmas, Amazon Developer gave to me… AWS Lightsail! 🎵 I need a secure cloud box to run Kiro CLI, Codex, Claude Code, and batch scripts without exposing my home network. Lightsail from Amazon Web Services (AWS) was able to get me up and running in minutes for under $5/month Here's my workflow: 📱 iSH (https://ish.app/) – SSH terminal for iOS 📂 Textastic (https://lnkd.in/gKee8EC5) – secure file transfer and SSH ☁️ Lightsail – my Ubuntu instance with an SSH alias as `tragbox` for quick access I SSH in, run either kiro-cli / claude / codex depending on the project, and my custom agents are live from my phone. Plus, I have a few MCPs running including GitHub and Context7 for extended capabilities. My top use cases: - Pull conference speaker data and build tables of mutual connections - Run batch image cleanup and CSV processing when I'm away from my laptop - Execute long-running scripts without tying up my local machine Why Lightsail? I considered EC2, Fargate, and other options but all too much setup for my use case. Lightsail gave me an Ubuntu box with a straightforward console, flat monthly pricing (no surprise bills), and I can bump RAM or storage when I need it. It's firewalled away from my home network, so I'm not worried about exposing internal endpoints. It really just works - I spin up agents on demand, run what I need, and move on. Check it out: https://lnkd.in/gqQyZ35t Follow along for more Amazon developer as today is just Day 9 of our 12 days of Amazon Developer 🎄

linkedin.com

🎵 On the 10th day of Christmas, Amazon Developer gave to me… Kiro specs!

by mosesroth

To paraphrase Forrest Gump, vibe coding is a like a box of chocolates, you never know what you're gonna get.

Unfortunately, that’s not such a good thing. So what are you supposed to do?

Meet spec-driven development with Kiro

With specs, when you give Kiro a prompt, instead of building the app right away, it gives you three docs: 1. requirements, 2. design, and 3. tasks. These documents list exactly what Kiro intends to do when building your app. You can then review them, confirm if the specs follow your vision, and either edit them or give Kiro a new prompt.

That way your vibe coded app actually conforms to your vision.

For more info, check out (Eric Fahsl’s talk)[https://www.youtube.com/watch?v=ilFdh17hKic]

Spec-Driven-Development With Kiro.dev by Eric Fahsl | AI Meetup in Wrocław, September 2025 | Moses Roth

🎵 On the 10th day of Christmas, Amazon Developer gave to me… Kiro specs! To paraphrase Forrest Gump, vibe coding is a like a box of chocolates, you never know what you're gonna get. Unfortunately, that’s not such a good thing. So what are you supposed to do? Meet spec-driven development with Kiro: https://kiro.dev/ With specs, when you give Kiro a prompt, instead of building the app right away, it gives you three docs: 1. requirements, 2. design, and 3. tasks. These documents list exactly what Kiro intends to do when building your app. You can then review them, confirm if the specs follow your vision, and either edit them or give Kiro a new prompt. That way your vibe coded app actually conforms to your vision. For more info, check out Eric Fahsl’s talk: https://lnkd.in/gRhYubiV

linkedin.com

🎵 On the 11th day of Christmas, Amazon Developer gave to me…Checkpointing in Kiro 🎵

by knmeiss

Have you ever let an AI agent refactor your code, only to realize you want to try a different approach? Kiro's checkpointing feature lets you rewind to any point in your session with one click.

✨ Automatic checkpoint markers are added to your session as Kiro modifies code.
🔄 Easily test different approaches. If one doesn't pan out, you're one click from reverting to any point in your session to try another.
💬 Retain your conversation context while reverting changes.
✔️Available in both the Kiro IDE and CLI

While it doesn’t replace version control, it does provide an experimentation playground while Git handles the permanent record.

The real gift? The confidence to experiment without fear 🎄🎁

🎵 On the 11th day of Christmas, Amazon Developer gave to me…Checkpointing in Kiro 🎵 Have you ever let an AI agent refactor your code, only to realize you want to try a different approach? Kiro's… | Kourtney M.

🎵 On the 11th day of Christmas, Amazon Developer gave to me…Checkpointing in Kiro 🎵 Have you ever let an AI agent refactor your code, only to realize you want to try a different approach? Kiro's checkpointing feature(➡️ https://lnkd.in/gRKCxyvZ) lets you rewind to any point in your session with one click. ✨ Automatic checkpoint markers are added to your session as Kiro modifies code. 🔄 Easily test different approaches. If one doesn't pan out, you're one click from reverting to any point in your session to try another. 💬 Retain your conversation context while reverting changes. ✔️Available in both the Kiro IDE and CLI While it doesn’t replace version control, it does provide an experimentation playground while Git handles the permanent record. The real gift? The confidence to experiment without fear 🎄🎁 ➕ Follow along as today is Day 11 of our 𝟭𝟮 𝗗𝗮𝘆𝘀 𝗼𝗳 𝗔𝗺𝗮𝘇𝗼𝗻 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿 🎄

linkedin.com

🎵 On the 12th day of Christmas, Amazon Developer gave to me . . . Alexa+ 🎵

by emersonsklar

If the past year has proven anything, it’s that conversational AI and voice assistants are very much back in the spotlight. Our friends in the industry have absolutely reinvigorated excitement in this space, and, candidly, their very visible rough edges have made one thing clear: this is still hard to get right. Which is exactly why I’m so excited about Alexa+.

🚀 What’s different this time?
Alexa+ represents a step-change from the original Alexa experience:

More natural, contextual conversations
Better reasoning and follow-through, not just command → response
Deeper integration across devices and services
Designed to feel less like a skill invocation and more like an assistant that actually gets what you’re trying to do

🤖 Why now?
Let’s be honest. Many of us have had recent moments with other assistants where we thought: “Wow… this should be better than this by now.” The good news? That bar (currently lying on the floor 😅) makes it even easier to be genuinely excited about what Alexa+ brings to the table.

🌟 Why developers should care
This isn’t just a UI refresh—it’s a rethinking of how voice, AI, and agents come together. Alexa+ opens up new possibilities for building experiences that feel more human, more useful, and more embedded in everyday life. Our developer tools aren't publicly available yet, but stay tuned - we have some extraordinary new solutions currently in private beta that make it easier than ever before to make incredibly engaging, useful, and functional experiences.

I’m thrilled to see where this goes, and even more excited about what builders will create on top of it.

Alexa+ Revolutionizes Conversational AI with Natural Conversations and Deeper Integration | Emerson Sklar posted on the topic | LinkedIn

🎄 On the 12th day of Christmas, Amazon Developer gave to me… ✨ #Alexa+ ✨ If the past year has proven anything, it’s that conversational AI and voice assistants are very much back in the spotlight. Our friends in the industry have absolutely reinvigorated excitement in this space, and, candidly, their very visible rough edges have made one thing clear: this is still hard to get right. Which is exactly why I’m so excited about Alexa+. 🚀 What’s different this time? Alexa+ represents a step-change from the original Alexa experience: - More natural, contextual conversations - Better reasoning and follow-through, not just command → response - Deeper integration across devices and services - Designed to feel less like a skill invocation and more like an assistant that actually gets what you’re trying to do 🤖 Why now? Let’s be honest. Many of us have had recent moments with other assistants where we thought: “Wow… this should be better than this by now.” The good news? That bar (currently lying on the floor 😅) makes it even easier to be genuinely excited about what Alexa+ brings to the table. 🌟 Why developers should care This isn’t just a UI refresh—it’s a rethinking of how voice, AI, and agents come together. Alexa+ opens up new possibilities for building experiences that feel more human, more useful, and more embedded in everyday life. Our developer tools aren't publicly available yet, but stay tuned - we have some extraordinary new solutions currently in private beta that make it easier than ever before to make incredibly engaging, useful, and functional experiences. I’m thrilled to see where this goes, and even more excited about what builders will create on top of it. 🎁 Onward to Christmas (and with a cheeky little tune, generated with Alexa and Suno - https://lnkd.in/gnDvzW_m) #AmazonDeveloper #AlexaPlus #ConversationalAI #VoiceAI #GenerativeAI #AWSreInvent #BuiltOnAWS

linkedin.com

And with that we would like to leave you with a cheeky tune created by Alexa and Suno!

[Boost]

Anisha Malde — Mon, 11 Aug 2025 12:19:19 +0000

Danny

Aug 11 '25

React Native Web with Vite

#vite #reactnative #react #storybook

8 min read

The hidden costs in your package.json

Anisha Malde — Fri, 11 Jul 2025 12:44:40 +0000

How do you choose what goes in your package.json?

Is it based on what the team’s used before? What has the most GitHub stars? Or because some article on dev.to told you to use it? 😶

As a React (Native) Developer, this was something I never really thought about until TV development forced me to. Think about the performance gap between an iPhone and a Fire Stick - devices with 1GB of RAM don’t give you room for extra library 'costs'.

Why? Your library choices directly affect how fast your app feels to users because your JavaScript bundle size impacts Time to Interactive (TTI - how long it takes for the app to become fully interactive after the initial load), memory usage, and CPU usage during run time.

So while an extra 100KB might feel negligible on mobile, we’re rarely just building for mobile. Every library decision, gets amplified and can carry hidden ‘costs’ across the hardware spectrum our apps now have to support.

Let's take an example, a commonly suggested swap - moment.js for date-fns:

We can use bundlephobia.com to quickly check the ‘cost’ of adding a npm library to your bundle. Upon checking, it tells us moment.js clocks in at around 300KB, while date-fns is a much leaner 77KB:

Okay so we should definitely use `date-fns` right? 🧐

Well since I no longer trust anything on the internet 👀, I did some more digging. I added each package to a clean app and then analysed the actual JS bundle using Expo Atlas(you could also use react-native-bundle-analyzer) and something surprising happened. date-fns showed up as the larger library:

Wait — waat?

date-fns is architected as 300+ small utility files, each doing one thing. Now that’s great if your bundler is properly configured for tree shaking — it can strip out unused code, and only include what you call. But for React Native developers, like me, the metro bundler isn’t configured for tree shaking by default. Now while it is currently experimental with Expo, if you aren’t tree shaking, or your import patterns are off —

import * from 'library'

— you end up bundling all 300 files, whether you use them or not.

At this point your probably still like:

Okay, So?

Its just a few extra KBs, how bad can it be? Well I decided to measure what those extra KB’s did to my app’s perceived speed. I created a simple Android app using React Native & Expo and rendered the date using each library. I then used our Fire-OS perf testing tool to see how each library would perform on my Amazon Fire Stick. The results were 😲

Those 200KB increased our time to interaction (latency) from cold start by 3%:

Now this is just an example but this could be any library.

So here’s the thing, a library might look super helpful but it always comes at a cost. And with a broad spectrum of devices, those costs hit harder. So how can we weigh up the costs? Heres a my -

Checklist for adding a library

First, as we saw, check the actual bundle size on your target platforms
Then measure the performance cost
And finally consider platform quirks e.g. FlashList might work on mobile but on TV platforms it might not have the functionality to handle the the dynamic, focusable content we have to deal with.

So don’t wait for the hidden costs to sneak up on your app performance.

Be deliberate. Be Critical. Every library in your package.json should earn its place 🏅

An Android Developer's Guide to React Native

Anisha Malde — Wed, 12 Mar 2025 14:43:10 +0000

Thinking of transitioning from Android to React Native? Hopefully this guide will help with the mental shift of learning React Native development from an Android background. But don’t worry, I won't tell anyone you're experimenting with "the other side", your secret's safe with me! 😉

Your learning experience going from Android to React Native will largely depend on your existing Android development background. Coming from 'traditional' View/XMLbased Android development, you will have a different learning curve compared to those with Jetpack Compose experience. If you're already familiar with Compose's declarative UI model, you are in luck ☺️, you'll find parallel concepts in React Native's component based approach. However, if you've been working with XML layouts and imperative View manipulations, the mental shift will likely be more substantial.

Regardless of your starting point, we will look at the main concepts that are different. Before we start, let's clarify some 'pre-requisites' to your React Native learning journey:

Learning JavaScript - While I won't go into the details of JavaScript vs Java/Kotlin, understanding JavaScript is essential since React Native targets TypeScript by default. Please, please learn JavaScript first to build a solid foundation.
Understanding React Fundamentals - React Native is built on React so you will need to understand React fundamentals as React Native components as the core concepts are the same. Due to this, everything in this article that refers to React will apply to React Native.

Thinking in React vs Android

When building a user interface with React, you follow a different mental model than Android development. In React, you will first break the UI into pieces called components. Then, you will describe the different visual states for each of your components. Finally, you will connect your components together so that the data flows through them.

In Android, your architectural approach will depend on your chosen UI framework. Here's a simplified comparison:

The most fundamental shift in thinking is that React doesn't have the same component segregation as Android. Android applications are structured around four main components and intents:

Activities: Entry points for user interaction, representing a single screen with UI
Services: Components that run in the background to perform long running operations
Broadcast Receivers: Components that respond to system wide broadcast announcements
Content Providers: Components that manage shared app data
Intent: An asynchronous message called that activates activities, services, and broadcast receivers

In a React App, most functionality centers around UI components and their state management, with background operations handled through different mechanisms.

If we were to loosely bridge our Mental Model:

Let's examine the composition of a typical React application and see how the architecture translates to the common building blocks of an App:

In React Native's you structure your application around components and their interactions which means it doesn't have a prescribed structure. Instead, it leaves it up you, to determine the best way to structure the app's components and data flow. It also means you'll need to make intentional decisions about how to organize your code.

A typical React Native project structure could look like this:

my-app/
├── android/                # Native Android project files 
├── ios/                    # Native iOS project files
├── node_modules/           # NPM dependencies (equivalent to Gradle dependencies)
├── src/                    # Your JavaScript/TypeScript code (like app/src/main in Android)
│   ├── components/         # Reusable UI components 
│   ├── screens/            # Screen components 
│   ├── navigation/         # Navigation configuration 
│   ├── services/           # API calls, business logic 
│   ├── hooks/              # Custom hooks 
│   ├── context/            # React Context definitions 
│   ├── utils/              # Helper functions 
│   └── assets/             # Images, fonts, etc. (like res/ directory)
├── App.js                  # Root component (comparable to Application class)
├── index.js                # Entry point (like MainActivity)
├── package.json            # NPM configuration (equivalent to build.gradle)
├── metro.config.js         # Metro bundler config (like gradle config)
├── babel.config.js         # Babel transpiler config 
└── tsconfig.json           # TypeScript configuration

Now that we've mapped the fundamental architectural concepts between Android and React Native and examined a typical project structure lets mentally map the core building blocks of a React Native application.

UI: Components, Layout and Styling

Component Mental Model

In Android, your UI building blocks are or Views/ViewGroups for traditional development and Composable functions for Jetpack Compose. In React Native, everything is a Component.

Traditional Android development is imperative, you manually manipulate the UI. React Native is declarative, you describe what the UI should look like.

Layouts

React Native uses Flexbox for layout, which differs from Android's traditional XML layout systems:

Layout Containers: Instead of LinearLayout, RelativeLayout, or ConstraintLayout, you'll use View components with flex properties
Units: No dp or sp, React Native uses platform independent units that automatically scale based on device settings
Positioning: Uses properties like justifyContent and alignItems rather than Android's gravity attributes

Styling

React Native provides a CSS-like styling system that will feel both familiar and different to Android developers as it combines concepts from web CSS and native mobile development:

Instead of XML style resources or Compose's modifier system, React Native uses JavaScript objects for styling. You then apply these styles to components either directly to components inline or using the StyleSheet API.

import { View, Text, StyleSheet } from "react-native";

function StyleExample() {
  return (
    // StyleSheet example
    <View style={styles.container}>
      // Inline example
      <Text
        style={{
          fontSize: 16,
          color: "blue",
        }}
      >
        Inline Style Example
      </Text>
    </View>
  );
}

// StyleSheet definition
const styles = StyleSheet.create({
  container: {
    padding: 16,
  },
});

No Resource Qualifiers: No built-in system for different screen sizes/orientations like Android's resource qualifiers
Responsive Design: Relies on percentage values, flex properties, and Dimensions API rather than different layout files
Style Resets: No global style inheritance by default; each component needs explicit styling

// In React Native, this won't work as expected:
<View style={{ color: 'red' }}>
  <Text>This text will NOT be red</Text>
</View>

// Each component needs explicit styling:
<View style={{ backgroundColor: 'blue' }}>
  <Text style={{ color: 'red' }}>This text will be red</Text>
</View>

Density Adaptation: While Android uses specific density buckets (mdpi, hdpi, etc.), React Native abstracts this away. All dimensions in React Native are unitless, and represent density independent pixels.
No XML Resources: No separate styling files or resource qualifiers like in Android
No Built in Theme / Design System: No direct equivalent to Android's theme system; theme typically managed with Context

State

Similar to the architectural differences, your approach to state management will vary based on whether you come from ‘traditional’ Android or Jetpack Compose.

Core State Components - Props, Hooks and Context

Props: Props (short for "properties") is immutable data passed from parent to child components. Since they are immtable they help make your components reusable.

In the Android world, props are similar to:

Arguments passed to a Fragment
Intent extras passed to an Activity
Parameters passed to a constructor

Hooks: Functions provided by React that lets a developer hook into React features from the component.

Context: Context provides a way to pass data through the component tree without having to pass props down manually at every level.

Core State Concepts

State as the Single Source of Truth
Instead of thinking about how to update the UI, think about what the UI should look like for a given state. The UI is a reflection of your state, not the other way around.

Components as Pure Functions
Given the same props/state, a component should always render the same way. Side effects are handled separately through useEffect.

Immutable Updates
Instead of modifying views in place, create new state that describes the updated.

Component Lifecycle

In traditional Android, you work with a set of lifecycle callbacks to manage an activities state throughout its existence, while React Native uses a simpler mount/unmount lifecycle model ‘accessed’ by the useEffect hook on a component level. Here's how they compare:

Navigation

In ‘traditional’ Android, navigation is primarily managed through the Intent system & Activity stack and with Jetpack Compose the Navigation Component. React Native navigation differs from Android in several ways:

No Built-in System: Unlike Android's core Intent and Activity systems, React Native doesn't have a built-in navigation framework. Instead you need to chose a 3P library, React Navigation being the most widely adopted solution.
Component-Based: Navigation is implemented through components rather than system level intents
Stack-Based Model: Similar to Android's back stack but implemented in JavaScript. Navigation routes and transitions are defined in JavaScript rather than XML or system calls.

While the fundamental concepts of navigation remain similar between Android and React Native, the implementation differs and can be mentally bridged as follows:

// Android Intent equivalent
function HomeScreen({ navigation }) {
  return (
    <Button
      title="Go to Details"
      onPress={() => {
        // Instead of startActivity() with an Intent
        navigation.navigate('Details', {
          itemId: 86,
          title: 'Product Details',
        });
      }}
    />
  );
}

// Accessing route params (similar to Intent extras)
function DetailsScreen({ route }) {
  const { itemId, title } = route.params;

  return (
    <View>
      <Text>Details for {title}</Text>
      <Text>Item ID: {itemId}</Text>
    </View>
  );
}

Business Logic

There is a significant mental shift when moving from Android to React Native in the relationship between UI and business logic.

In Android Development

UI and business logic code typically exist as coequal concerns
Architecture patterns like MVVM, MVP, or MVC clearly separate presentation from business logic
Backend code (repositories, services, managers) often feels as substantial as UI code
UI is frequently thought of as "just the view" that renders the data

In React Native Development

UI components and business logic are more tightly integrated
Components execute both presentation and logic behavior
The architecture is more "UI forward" with logic serving the UI
Hooks blend UI and logic concerns within the same component

In React Native, you'll likely find yourself starting with the UI and then adding the logic it needs, rather than designing backend services first. This "UI driven" approach stems from React's component based architecture, where components are the primary building blocks. As projects grow in complexity, you might still extract pure business logic into custom hooks, contexts, or services as seen in the example project structure above. As you continue your React Native journey, you'll likely develop your own style for balancing these concerns

While React Native changes how you structure your UI and business logic relationship, the backend services (API clients, data parsing, and state synchronization) remain conceptually similar to Android and your backend services can power both Android and React Native apps. In React Native, the libraries you'll typically use:

Fetch or axios for API calls
AsyncStorage for data persistence
Native Modules for Platform API / Capabilities

The key difference isn't in what backend services you need but in how they integrate with your component structure. You'll often create custom hooks that encapsulate data fetching and state management, then consume these hooks directly in your components.

Further Learning

Hopefully this guide helps you mentally map React Native to some familiar Android development concepts, but remember that this mental mapping is just the beginning. While these comparisons provide a start for understanding how React differs from Android, they aren't a substitute for deeper learning and practice. To continue your React Native learning journey, here are some valuable resources:

React Native Official Documentation
React Native: The Practical Guide on Udemy
Expo - React Native framework

Hopefully I’ll see you on "the other side" 😉

How does React Native's New Architecture affect performance?

Anisha Malde — Thu, 06 Feb 2025 17:37:19 +0000

What is the New architecture?

React Native's new architecture was introduced in version 0.68 and was made default in 0.76. It was built to unlock capabilities and improvements that were not possible in the legacy architecture. Switching to the new architecture unlocks these new capabilities which in turn can help improve the performance of your apps. I say can because performance improvements will vary depending on how your app is designed, implemented and built.

The new architecture comprises of Fabric, Turbo Native Modules, Codegen, and the JavaScript Interface (JSI).

How can each pillar affect performance?

Fabric, the new rendering system, enables more efficient UI updates by minimising the time it takes to update the UI, including smoother scrolling, more responsive focus changes, and fluid animations.

Turbo Native Modules are the next iteration of Native Modules that address the asynchronous and loading problems by lazy loading modules. Turbo Native Modules can improve performance as by bypassing the JavaScript bridge and directly communicating with native code, they reduce the overhead of communication between JavaScript and native code. This can mean faster app startup and quicker response times from the Native layer, addressing a common pain point in the app user experience where users expect instant responsiveness.

JSI (JavaScript Interface) eliminates the overhead of the bridge by providing an abstraction layer to the JavaScript Runtime. This synchronous communication significantly reduces latency, creating more fluid interfaces.

Codegen enhances type safety and reduces runtime overhead. Additionally, Codegen facilitates the creation of JSI bindings, and utilizing these bindings allows your app to achieve faster and more optimized communication between the native and JavaScript layers, leading to more stable and efficient apps.

Finally the New Architecture adds full support for modern React features, including automatic batching which is when React groups multiple state updates into a single re-render for better performance and now this will happen automatically.

Testing Performance

As mentioned the performance improvements will vary depending on your specific app structure. However in order to do some basic tests Meta created an App that benchmarks the old vs new architectures.

They measured an average of five measurements on physical mobile devices running React Native 0.72.0-RC.1 and the results can be found here.

I modified the app to run react-native-tvos@0.73.6-0 to add TV support. You can find my repository here.

Additionally, I created a typical MovieCard component consisted of a View, Image and 2 Text elements and took an average of 5 measurements when rendering the component 1500 times using both the old and new architecture.

Results

Performance is particularly important for Apps that run on TV devices as these devices typically have resource constraints. Due to this, I decided to test on the Android TV emulator and 2 of our Amazon Fire Devices - a Tablet and a TV Stick.

On a 1080p TV emulator running Android 14 there was an average of ~500ms improvement when using the New Architecture.

On a Fire HD Plus tablet (10th Generation) running Fire OS 7.3 there was an average of ~900ms improvement when using the New Architecture.

On a Fire TV Stick HD running Fire OS 7.6 there was an average of ~1000ms improvement when using the New Architecture.

Old Architecture

New Architecture

Note: On the Fire TV, I had to use a mouse as the performance was measured using a TimeStamp value that was only generated when the onPress of the button was triggered by 'touch'. I will try to add this value to the onPress event object to be included even when the onPress is triggered by the D-Pad enter key.

Average Results

Community Testing

There are other developers that have seen improvements in performance by switching to the new architecture. Kraken saw render times got significantly faster, but with large variability between different screens and the biggest improvement on the slowest devices.

You can also see some UI benchmarks from Alexandre who is a maintainer of the React Native performance measuring tool, Flashlight.

Moving to the New architecture

While the performance benefits of migrating to the new architecture depend on the app, the UI improvements are clear. Although the transition requires effort, the long-term benefits of Fabric, Turbo Native Modules, JSI, and support for the latest React features like Suspense and Concurrent Mode, make it a worthwhile investment.

You can find the full instructions in the dedicated working group on how to migrate to the new architecture. You can also test out the benchmark app with your own scenarios or my TV supported fork of the benchmark app here.

How does React Native’s New Architecture affect performance?

Anisha Malde — Thu, 06 Feb 2025 16:44:43 +0000

What is the New architecture?

The new architecture comprises of Fabric, Turbo Native Modules, Codegen, and the JavaScript Interface (JSI).

How can each pillar affect performance?

Testing Performance

As mentioned the performance improvements will vary depending on your specific app structure. However in order to do some basic tests Meta created an App that benchmarks the old vs new architectures.

They measured an average of five measurements on physical mobile devices running React Native 0.72.0-RC.1 and the results can be found here.

I modified the app to run react-native-tvos@0.73.6-0 to add TV support. You can find my repository here.

Results

On a 1080p TV emulator running Android 14 there was an average of ~500ms improvement when using the New Architecture.

On a Fire HD Plus tablet (10th Generation) running Fire OS 7.3 there was an average of ~900ms improvement when using the New Architecture.

https://asset.cloudinary.com/dd6mweway/1e8b4d0ff24f1858387d0c65338b6a63

On a Fire TV Stick HD running Fire OS 7.6 there was an average of ~1000ms improvement when using the New Architecture.

Old Architecture

New Architecture

Note: On the Fire TV, I had to use a mouse as the performance was measured using a TimeStamp value that was only generated when the onPress of the button was triggered by 'touch'. I will try to add this value to the onPress event object to be included even when the onPress is triggered by the D-Pad enter key.

Community Testing

You can also see some UI benchmarks from Alexandre who is a maintainer of the React Native performance measuring tool, Flashlight.

Moving to the New architecture

My React(Native) New Years Resolutions

Anisha Malde — Mon, 30 Dec 2024 17:02:57 +0000

As we approach 2025, here are seven promises (not the async kind) that I'm making to myself to help improve my TS/React/React Native development habits:

1. I will stop using console.log('wtaf 🫠')
I confess that using console.log('test1'), console.log('test2'), console.log('aaaarghhhhhhduhsufh') may no longer be the best debugging strategy and I really should start using React Native DevTools!

2. I will not ignore my TypeScript errors by using :any
I admit that adding :any to silence my TypeScript errors is the development equivalent to 'New phone, who dis?' 😶‍🌫️

3. Like my wardrobe, I will do a better job at cleaning up my useEffects
and stop using [ ] as a dependency, which is basically like shoving everything into my wardrobe before guests arrive. It's all dandy until you open the door and everything falls out #MemoryLeak🚰.

4. I will not use the React Compiler as an excuse to stop improving my understanding of how to use the useMemo & useCallback hooks.
Let’s be honest: using useMemo to optimize performance is like almond milk — trendy but expensive. Unless you’re “lactose intolerant” (or, to be technically correct, actually dealing with expensive computations), it often introduces unnecessary overhead without delivering meaningful performance improvements.

5. I will test on real devices!
So this means for Amazon Auto, I need a car right? 🏎️

6. I will stop using the SafeAreaView as a bandaid 🩹
Okay so wrapping every single component in SafeAreaView isn't going to fix my layout issues. Or is it? 😏

(For all my React Native TV developers)

7. I will stop treating my focus bugs 🐛 as features
Because I don't think I can convince my designer "pressing the back button three times to reach the menu" will become a really cool new UX pattern.

P.S. We all know I'll break at least three of these. But hey, like my going to the gym resolution, it still counts if I wear the my workout clothes while coding, right?

Disclaimer: I should clarify that I've obviously never made any of these mistakes. Any resemblance to actual coding practices is purely coincidental, and my manager should definitely not check my git history. 👀

What are your Re(act)solutions?

How to develop a React Native TV App

Anisha Malde — Tue, 10 Dec 2024 18:49:18 +0000

By Anisha Malde & Karol Latusek

If you are reading this article, you are likely familiar with the complexities and fragmentation of TV app development, and like us, you've turned to React Native as a solution. It's an exciting use case of React Native, with the community making significant progress in this space—most notably, Expo introducing TV support in Expo SDK 50 earlier this year.

Inspired by our own experiences (& struggles 😅), we decided to create a comprehensive guide to using React Native for TV.

Since using the React Native framework, Expo, is now the recommended approach to creating new apps, our guide focused on this. However, during our post-launch discussions, we realized there were still developers who wanted to know how to set up a bare React Native (RN) project for TV. That’s why this article will explore how to set up your bare RN project and expand on how to set up your project to build for multiple platforms.

Expo or Bare React Native?

There are two different ways to get started with TV development: Expo and Bare React Native. Your choice between these approaches will depend on several factors such as project complexity, performance needs, and the specific TV platforms you are targeting.

Building a TV App With Expo

Expo presents a quicker route to TV app development by reducing the complexity of setting up your development environment. It offers out-of-the-box support for multiple platforms (web, TV, and mobile) and pre-configured build processes. Expo is ideal for getting started quickly! 🚀

How to get started

You can find more information in this Expo documentation or the ‘Getting Started’ chapter in our guidebook.

Building a TV App With Bare React Native

On the other hand, Bare React Native can offer developers more control. It is ideal for projects that require specific build processes or have unique performance requirements.

How to get started

If you are starting a Bare React Native project, the easiest way to ensure your project is configured for TV is to use the React Native community CLI template:

npx @react-native-community/cli@latest init TVTest --template @react-native-tvos/template-tv

This creates a project with react-native-tvos and all the required configurations for Android and TvOS.

Adding TV Support to an Existing Project

If you have an existing React Native project and want to add TV support, you need to handle these configurations to extend it to build TV apps. Note that the above template takes care of this for you.

1. Update package.json dependencies

"react-native": "npm:react-native-tvos@latest"

This enables your project to use a fork of React Native, react-native-tvos, with the changes needed to support Apple TV and Android TV.

💡 You cannot use this package and the core react-native package simultaneously in a project however using the fork doesn’t prevent you from creating your ‘regular’ mobile builds.

2. Update Android Manifest

For Android TV applications you need to ensure that your app is declaring a launcher activity by adding the leanback launcher to your Android manifest file:

<intent-filter>
  <category android:name="android.intent.category.LEANBACK_LAUNCHER" />
</intent-filter>

Without this, your application will not be discoverable on Google Play, and it will not be recognized as a TV app that appears on the system's home screen after installation (the app will only be visible in Settings > Apps > All Apps.)

Declare that the android.hardware.touchscreen feature is not required and that your app is built for Android TV:

<uses-feature android:name="android.hardware.touchscreen" android:required="false" />
<uses-feature android:name="android.hardware.faketouch" android:required="false" />

Declare that your app is built for Android TV:

<uses-feature android:name="android.software.leanback" android:required="false" />

For more information on these changes, read the Android documentation on adding TV support.

💡 We recommend adding these changes to the TV apps' Android manifest only. If your app is targeting different build platforms in addition to TV, you still want to make sure that the platform domain features, e.g., touchScreen is required on the mobile build.

We explain how you can structure your app to have separate manifests below.

3. Update Project.pbxproj

Update the iOS project file to define support of TVOS according to this.

4. Update Podfile

- platform :ios, min_ios_version_supported
+ platform :tvos, min_ios_version_supported

This ensures your project is being configured for tvOS.

Structuring Your App to Handle the Additional TV Platform

One of the biggest advantages of React Native is the possibility to use one codebase for multiple platforms. This is also the case when you create builds for TV. However, mobile and TV projects may need separate package.json, podfiles, and Android manifests.

How can you structure your app to handle this? One option is to structure your project as a monorepo:

Check Oskar’s article for details on a monorepo setup with Yarn workspaces. This allows flexibility as we can separate TV related code from the mobile and can also expand it to other TV platforms e.g. WebOS, Tizen.

Another approach for smaller projects use a structure similar to the template and differentiate Android TV and Android Mobile specific feature sets on the build flavour level and then by merging manifests.

Whether you choose the Expo route or the Bare React Native approach, adding TV support to your app requires just a few steps. We hope this helps you get started on your TV development journey. Check out the guidebook for more tips and tricks on building for TV using React Native. If you have any questions or requests for content you'd like to see in the book, please leave a comment below ⬇️

DEV Community: Anisha Malde

Building High Quality Streaming Apps: The Blueprint

Why teams need the same quality view

How this relates to implementation guidance

The six pillars

What’s next

Building a Dev Content Strategy that survives Monday

Step 1: Get all the ideas on the table

Step 2: Pick the right format for each idea

Step 3: Map each idea to a stage of the developer journey

How we decide what to create

Agents & Agent Orchestration, MCP, Skills, Context, Prompt & Harness Engineering 🤯: What, When, Where, How?

The What & When

Prompt engineering: refining intent

Context engineering: managing information

Agents & Agent Orchestration

Harness engineering: controlling execution

How: it all fits together

Tactics for making it work

Where: tools for building your harness

Layer 1: ready-made harnesses (mostly for coding tasks)

Layer 2: build your own with an SDK

Layer 3: host it somewhere

The cross-cutting bits

Conclusion

To Share or Not to Share: Building for multi-platform

The shared workspace approach

The tooling that makes sharing work

What makes sense to share

Business logic and state management (share it)

UI components (share most of it)

Navigation and screen flows (share with care)

Layout and theming (share the system, tweak per platform)

What you should keep separate

Media Player

Amazon specific features

Vega UI Components (VUIC)

Native modules and DRM

Try it yourself: the Hello World starter

See it in production: the Multi-TV App Sample

Migrating your own app: the AI-assisted approach

Phase 1: Analyse your codebase

Phase 2: Build the shared workspace structure

Phase 3: Add OS-specific implementations

Best practices

Get started building today:

🎵 On the 12 Days of Christmas, Amazon Developer gave to me... 🎵

🎵 On the 1st day of Christmas 🎄, Amazon Developer gave to me… voice generation with Polly 🎵

🎵 On the 2nd day of Christmas 🎄, Amazon Developer gave to me… Kiro power🎵

🎵 On the 3rd day of Christmas, Amazon Developer gave to me… 3 CLI Custom Agents 🎵

🎵 On the 4th day of Christmas, Amazon Developer gave to me… Kiro CLI: https://kiro.dev/cli/

🎵 On the 5th day of Christmas, Amazon Developer gave to me… Amazon Bedrock 🎵

🎵 On the 6th day of Christmas 🎄, Amazon Developer gave to me… browser automation with Amazon Nova Act 🎵

🎵 On the 8th day of Christmas 🎄, Amazon Developer gave to me ... one prompt UI magic with Kiro ✏️ 📺 🎵

🎵 On the 9th day of Christmas, Amazon Developer gave to me… AWS Lightsail! 🎵

🎵 On the 10th day of Christmas, Amazon Developer gave to me… Kiro specs!

🎵 On the 11th day of Christmas, Amazon Developer gave to me…Checkpointing in Kiro 🎵

🎵 On the 12th day of Christmas, Amazon Developer gave to me . . . Alexa+ 🎵

[Boost]

The hidden costs in your package.json

How do you choose what goes in your package.json?

Let's take an example, a commonly suggested swap - moment.js for date-fns:

Okay so we should definitely use date-fns right? 🧐

Wait — waat?

Okay, So?

Checklist for adding a library

An Android Developer's Guide to React Native

Thinking in React vs Android

UI: Components, Layout and Styling

Component Mental Model

Layouts

Styling

State

Core State Components - Props, Hooks and Context

Core State Concepts

Component Lifecycle

Navigation

Business Logic

Further Learning

How does React Native's New Architecture affect performance?

Okay so we should definitely use `date-fns` right? 🧐