DEV Community: Amazon Developer

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 Workflow | 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!

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" 😉

📰 February 2025 @AmazonAppDev Newsletter

Chris Trag — Thu, 27 Feb 2025 06:00:00 +0000

From app submission to certification

Ensure your app is in top shape for a smooth submission process.

Streamline app management with App Submission API
Use the RESTful App Submission API to manage updates to your app with programmatic calls and automation.

Your personal app submission checklist
Check to see if your app meets all of the requirements before submitting. Read more ›

Avoid common pitfalls for app rejections
Meet Amazon's test criteria and quality standards before submission. Navigate policies around appropriate content, user privacy, and in-app purchases. Read more ›

Stay ahead of the trend

📊 New App Statistics Reports
Performant apps lead to better stats. Check how your app is doing with the new Acquisition and Engagement dashboards.
Read more ›

📺 Hello World for Fire TV with Jetpack Compose
Compose for TV introduces new components with clear focus indicators and remote-friendly input behavior.
Read more ›

Recent updates

⚠️ [Discontinuation Notice] Amazon Appstore for Android devices
As of August 20, 2025 Amazon Appstore for Android mobile devices will be discontinued. Starting on February 20, 2025, the option to submit new apps targeting Android devices will not be available. Updates to existing live apps on Amazon Appstore for Android mobile devices can be submitted until August 20, 2025.

⚠️ [Discontinuation Notice] Amazon Coins program
As of August 20, 2025 Amazon Coins Program will be discontinued in all marketplaces. Note that as of February 2025, customers will no longer be able to buy Amazon Coins. However, customers will be able to use their previously purchased Amazon Coins until August 20, 2025.

Appstore Billing Compatibility SDK is now on Maven Central
Easily port your Android app with Google Play Billing to the Amazon Appstore, with minimal changes.

Developer highlights

Revamping your tech stack for the new year?
Solution Architect Matthijs Langendijk explores framework options for OTT apps, including React Native development for Fire TV, to help you choose the right tech stack for your streaming app.
Read more ›

Amazon GameLift scales to 100 million concurrent users (CCU) for a single game
Amazon GameLift provides scalability for game developers, supporting up to 100 million CCU while maintaining fast session allocation and seamless player experiences.
Read more ›

Related resources

💡 Visit the Amazon Developer Portal for all the updates, documentation, and resources.

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.

📰 January 2025 @AmazonAppDev Newsletter

Chris Trag — Mon, 27 Jan 2025 06:00:00 +0000

App performance

New guides and tools for upleveling your app, testing across devices, and monitoring performance

⏱️ Optimize your Fire TV app performance
Get answers to common issues to ensure your app provides a smooth, responsive streaming experience. Read more ›

✅ Testing made easier with Appstore Quality Central
Explore the new suite of tools for testing your app across virtual devices. Test results can help you improve quality, increase stability, and optimize user experience for a streamlined certification process. Read more ›

Inspect performance with the App Health Insights dashboard

Monitor key performance metrics for your Fire TV, Fire tablet, and Android apps with the App Health Insights dashboard.

Beyond "Hello World!"

eBook 📖 Mastering the Big Screen

We partnered with Callstack to address the unique challenges and solutions for creating high-quality streaming apps using React Native.
Download your copy ›

Bare React Native projects for TV

Bare React Native can be ideal for projects that require specific build processes or have unique performance requirements.
Read more ›

Developer highlights

🗓️ 2025 look ahead
@chris_trag shares upcoming events and developer courses he’s excited about for the new year.
Read more ›

📈 2024 Year in Review
ICYMI - We round up some of our favorite highlights from last year, including event tech talks, product and feature releases, and popular best practice guides.
Read more or watch the video ›

Related resources

💡 Visit the Amazon Developer Portal for all the updates, documentation, and resources.

Hello World for Fire TV with Kotlin & Jetpack Compose

Olivia Sung — Fri, 17 Jan 2025 17:42:19 +0000

With the release of Jetpack Compose for TV that came out during summer of 2024, Compose for TV introduces TV material components that are designed for the living room, with clear focus indicators and remote-friendly input behavior. Now there is a specific dependency for TV androidx.tv:tv-material instead of using the mobile one such as androidx.compose.material3:material3.

In this tutorial, I will be following closely on a ‘📺 🔥 Hello World Fire TV App’ sample recently published on GitHub. I will be highlight some cool features that are used in this sample so that you don’t have to read through the code base! Once again for this tutorial, we will be using Google Jetpack Compose to design and implement tv navigation drawer.

Prerequisite

You can use an existing Fire TV or an Android TV virtual device.

Light/Dark Mode

Switching from light and dark mode depending on the device’s system theme is an industry standard nowadays.
We can use the isSystemInDarkTheme to check if the device system is in light or dark mode to help build responsive UIs that follow the system setting.

In Theme.kt, you can find below code snippet:

@Composable
fun HelloWorldTVTheme(
    isInDarkTheme: Boolean = isSystemInDarkTheme(),
    content: @Composable () -> Unit,
) {
    val colorScheme = if (isInDarkTheme) {
        darkColorScheme(
            primary = Purple80,
            secondary = PurpleGrey80,
            tertiary = Pink80
        )
    } else {
        lightColorScheme(
            primary = Purple40,
            secondary = PurpleGrey40,
            tertiary = Pink40
        )
    }
    MaterialTheme(
        colorScheme = colorScheme,
        typography = Typography,
        content = content
    )
}

Navigation Drawer

Navigation drawers are essential components in any TV app as they allow users to access different destinations and features. In our sample, we are using [ModalNavigationDrawer](https://developer.android.com/reference/kotlin/androidx/tv/material3/package-summary#ModalNavigationDrawer(kotlin.Function2,androidx.compose.ui.Modifier,androidx.tv.material3.DrawerState,androidx.compose.ui.graphics.Brush,kotlin.Function0)) as they are good for infrequent, but more focused, switching to different destinations. In HomeDrawer.kt, we are defining navigation drawer although we have not set any specific destinations.

ModalNavigationDrawer(
        drawerState = drawerState, drawerContent = { drawer ->
            Column(
                Modifier
                    .background(MaterialTheme.colorScheme.surface)
                    .fillMaxHeight()
                    .padding(12.dp)
                    .selectableGroup(),
                horizontalAlignment = Alignment.Start,
                verticalArrangement = Arrangement.spacedBy(
                    8.dp, alignment = Alignment.CenterVertically
                ),
            ) {
                Spacer(modifier = Modifier.height(8.dp))

                menuItems.forEachIndexed { _, item ->
                    NavigationRow(item = item,
                        isSelected = selectedId == menuItems.indexOf(item),
                        onMenuSelected = {
                            drawerState.setValue(DrawerValue.Closed)
                            onMenuSelected?.invoke(item)
                        })
                }
                Spacer(modifier = Modifier.weight(1f))
            }
        }, scrimBrush = Brush.horizontalGradient(
            listOf(
                MaterialTheme.colorScheme.surface, Color.Transparent
            )
        )
    )

Scrollable grid of cards

As this sample on GitHub is showcasing a catalog, we need a grid of cards where each card can represent a media of some sort. If it’s a media streaming app, you can imagine what these cards will be filled with, TV shows, movies, etc you name it! We are using [LazyVerticalGrid](https://developer.android.com/develop/ui/compose/lists#lazy-grids) which will provide support for displaying items in a grid. As we want something scrollable with a remote, vertical grid will display items in vertically scrollable container so users can scroll up and down!
For this sample, we want 5 columns so we will declare GridCells.Fixed(5).

LazyVerticalGrid(
                columns = GridCells.Fixed(5),
                contentPadding = PaddingValues(
                    start = 24.dp,
                    top = 24.dp,
                    end = 24.dp,
                    bottom = 48.dp
                ),
            )

In the end, when you run the sample app, you will have a scrollable TV app with grid of cards!

Conclusion

Today we went over some quick pointers on the Hello World Fire TV sample on GitHub which includes features such as different light/dark mode, navigation drawer and scrollable vertical grid to look similar to an streaming app on TV.

Stay connected

Stay up to date with Amazon Appstore developer updates on the following platforms:
📣 Follow @AmazonAppDev on Twitter
📺 Subscribe to our Youtube channel
📧 Sign up for the Developer Newsletter

5 cool things from CES for Amazon Developers (plus 4 more!)

Moses Roth — Wed, 15 Jan 2025 19:23:36 +0000

CES is one of the biggest electronics shows in the world, and this year I got to go for the first time. The 2025 show just wrapped up and if you were there and stopped by Amazon’s showcase, you might have seen me or even chatted with me about Fire TV.

The show is huge. If you spent all week just checking out as many booths as you could, you still wouldn’t see everything.

So whether you were able to attend or not, here are 5 highlights for Amazon Developers (and a few other cool things too):

AI-enhanced voice search on Fire TV with Alexa

Amazon was demoing the new AI-enhanced search on Fire TV with Alexa, which will help you find a show or movie, even if you don't remember the title or don't know exactly what you want to watch.

You can try it now on your Fire TV at home, it’s already live! Here are some examples you might try:

“TV show about dragons”

“Tom Cruise sci-fi action movie”

“Movie where they say ‘life is like a box of chocolates’”

Try it out and see if you get the results you expect. I bet you’ll be impressed.

This is great news for developers, because it means customers can now find your content a lot more easily. As long as your show or movie is integrated in the Amazon catalog, it will appear in the search results.

Cars with Alexa and Fire TV integrated

Amazon is working on integrating Fire TV, AWS, and Alexa into cars and we had the Acura ZDX and the BMW X3 M50 on display. I got the chance to try it out by sitting in the car and giving Alexa commands.

Be sure to target Automotive devices, so that cars with Fire TV will be able to run your app.

Echo Show 15 and 21

One cool thing about the new, bigger Echo Shows is that they are like mini-Fire TVs. They come with a Fire TV remote and customers can play Fire TV apps and channels on them.

Don’t forget to target these devices, so you can reach a whole new audience with your app!

Fire TV 85" Omni Mini-LED and Soundbar Plus with surround sound

One of the most fun demos we did was Amazon’s 85“ Fire TV and Soundbar Plus with subwoofer and surround sound speakers. We took people into a soundproof room and played The Lord of the Rings: The Rings of Power for them so they could feel the Dolby Atmos. Make sure your content is set up to take advantage of it, because it sounds awesome, and it will bring a whole new level of performance to your app.

AI-generated images on Fire TV

We were also showing off Fire TV’s new ability to create AI-generated images. You can try it right now on your own device. Just use your remote to say, “Alexa, generate an image of dogs jumping on the moon” or I’m sure you’ll come up with some ideas more creative than me!

4 other things...

Obviously, it wasn’t just Amazon at the show, so here are 4 other cool things I saw at CES that impressed me.

Delorean

Clarios somehow managed to get a Delorean from Back to the Future to the show. Pretty cool.

Boring Company/Tesla loop

CES is huge. To get around the 3 parts of the Las Vegas Convention Center, they offered free rides in Teslas through Boring Company tunnels. Very cool.

Holograms

Hypervsn was showing off this crazy 20 foot tall hologram. The photo doesn’t quite do it justice, but it was impressive.

Zoox robotaxis

Okay, this one is technically part of Amazon, but I had to mention it too. Zoox is currently testing its automated taxis in Las Vegas, and they were offering demo rides for those lucky enough to get one.

That was my CES experience and I’m super glad I got the chance to go. Let me know if there was anything you loved at CES that I missed, and hopefully I’ll see you there next year!

2025 look ahead: Top dev events & courses for Android, React Native, and GenAI

Chris Trag — Fri, 20 Dec 2024 05:45:21 +0000

To prepare for an action-packed 2025, here are several upcoming events and developer courses I’m excited about. For the New Year, I’m focusing on 3 areas to dedicate my time and energy:

Android: Up-level Android & Unity development skills to build faster apps and games
React Native: Sharpen the toolkit to launch new tablet & Smart TV apps
GenAI: Attend workshops and meetups to learn what’s next with building LLM-powered products

This guide is by no means definitive; If you have any events, courses, or meetups you want to share, let me know in the comments below 👇 💬

Android & Gaming

CES 2025 - Las Vegas (Jan 7th - 10th)

The Consumer Electronics Show is the world’s largest technology event and where we discover the first major announcements of the year from over 4,000 tech brands exhibiting their products and services. The Keynote lineup offers up mix of industry leaders from across the Automotive, Travel, AI, and Tech, and Entertainment. Personally, I am excited to walk through the CES 2025 Innovation Awards® showcase in the Venetian Expo, Hall A, especially the Best of Innovation category winners to see these up close.

If you’re attending CES for the first time, I suggest some comfortable walking shows since there’s over 2.5 million square feet for the showroom exhibits. If you’re interested in the suite of Amazon devices and products, my colleagues and I will be over in the Amazon at CES 2025 experience (Venetian Ballroom G-H) — Feel free to send me a note on Bluesky or LinkedIn if you plan to stop by!

2025 Droidcon events (multiple dates)

The Android community does a great job with talks and sessions at all the local Droidcons. Each city has a unique take that I find refreshing compared to many conferences I spend time at. This year I want to dive deep into Kotlin Multiplatform, better understand the latest features in Jetpack, and find out about the recent updates for Android worth incorporating.

The organizers also launched Droidcon Academy for mastering in-depth topics through codelabs, new learning paths, and talk recordings.

As I shared in last year’s post, I am partial to the London Droidcon since it’s been great for several years in a row. If you have a favorite of the Droidcon locations, I would love to know in the comments below!

Android Training Courses & Certificates

The Android team has a mix of beginning and advanced Android, Kotlin, and Compose online course on their developer site.

Here are my favorite courses and codelabs offered:

Android Basics with Compose to get moving quickly
Jetpack Compose for Android developers walks through the toolkit for building better Android UIs
Android app architecturefor improving the quality and structure of your apps

Tokyo Game Show 2025 - Tokyo, Japan (September 27th - 29th)

東京ゲームショウ (TGS) is a blast to attend and is a great way to know what’s launching for upcoming video games and new hardware, especially from Japan based publishers. The general exhibition area is for digital gaming demos from the top titles along with upstart game studios.

Watch the sessions from this year’s show here: expo.nikkeibp.co.jp/tgs/2024/en/program/official

React Native

The React Summit(s) - Amsterdam & NYC

The GitNation team puts on two major events each year:

React Summit in Amsterdam from June 13th to 17th, 2025
React Summit NYC in November 2025 (Exact dates TBD)

These two are a hybrid of workshops, sessions, and on-demand content to follow-up on afterwards. Attend the events if you want to connect with both React and React Native app builders working on similar challenges using these frameworks. I’ve really enjoyed the networking and mix of attendees, especially the React open source awards portion of the days. Keep in mind the virtual ticket provides all the sessions for on-demand access via the GitNation site — however you choose to attend it’s worth checking out.

New Course: React Native Mastery

React Native Mastery is the latest course from Vadim & the notJust.dev team and is the top referred course these past few weeks. They aim to provide “the only course you need to Master mobile development with React Native & Expo.” What’s different than most online courses is how it focuses on learning through full-featured sample apps. To start, the course offers up Quiz, Camera, Forms, and Business card samples as the first four modules.

React Conf 2025 (Date TBD)

Attending React Conf 2024 was a highlight for my year — the networking, the sessions, and the announcements in particular were stellar. Co-hosted by Meta and Callstack, these teams did a great job partnering up to bring the event to life. Over the two days of sessions, there were 600+ in-person attendees and over 250k+ online viewers — check out the 2024 talk recordings at conf.react.dev/talks.

The date for 2025 is still to be determined so I’d suggest keeping an eye on conf.react.dev

Anisha Malde and I presenting at React Conf 2024. You can watch our session on YouTube.

AppJS 2025 - Kraków, Poland (May 28th-30th)

AppJS is one of my favorite annual developer conferences for how in-depth and thorough the talks and workshops are. The Software Mansion team leans heavily into the specifics of React Native for Mobile, Brownfield apps, and optimization tooling. If you’re building with Expo and React Native, this is the conference you cannot miss in 2025.

My colleagues Gio and Eric at AppJS teaching how to extend React Native apps for the Big Screen.

Chain React Conf - Portland, Oregon (Date TBD)

Infinite Red puts on a highly technical set of developer talks dedicated to React Native. Attendees get to connect with many of the core contributors and lead maintainers across the React Ecosystem. Personally, I would recommend arriving a day earlier to attend the workshops.

Watch the 2024 sessions at chainreactconf.com/events/2024

React Universe 2025 - Wroclaw, Poland (September 2nd - 4th)

React Universe (formerly React Native EU) is great for teams building with React and React Native across devices and app stores. The team at Callstack pulls together quality sessions that span everything from VR development to core maintainer announcements. While the conference is in latter part 2025, I’d recommend checking out their engineering podcast callstack.com/podcast.

Here is our panel discussion on building apps for Mobile, Web, and Smart TVs

Gen AI & LLMs

AWS Advanced AI and Tool Use Meetup - San Francisco (January 16th, 2025)

The AWS GenAI Loft in San Francisco is hosting several developer meetups and workshops including the Advanced AI and Tool Use Meetup with Toolhouse.ai in January. This free hands-on session will help you learn how to build efficient AI assistants and network with fellow developers and AI experts.

Event details: aws.amazon.com/startups/events/advanced-ai-and-tool-use-meetup
RSVP link: lu.ma/0r7kp1lm

DeepLearning.AI - Generative AI for Everyone

This free set of courses is designed to help you master the fundamentals of Generative AI, learn real-world examples of tools in use, and better understand the impact on society and business. I really enjoy this curriculum because it starts at the very beginning in order to build a foundation to learn practical ways to incorporate this tech into your products and apps.

In addition to these 101 lessons, the AWS team contributed two courses on Agentic Workflows and deploying Serverless LLM Apps with Amazon Bedrock.

More information at deeplearning.ai/courses/generative-ai-for-everyone

Where to find more developer events and courses?

There’s a lot happening across these developer communities so I’d suggest subscribing to these channels:

Google’s Android Developer Updates are sent directly from the Android team with a mix of video, articles, and upcoming events. For something a bit more community-led, I’d recommend subscribing to Android Weekly. For product updates related to Fire OS, make sure to subscribe to our monthly newsletter.
This Week In React is currently the top newsletter on what's happening across React & React Native so definitely subscribe if you're interested.
Unity has their own newsletter for product announcements and tips. In addition, the Unity dev community shares the latest on Game Dev Digest, X, and Discord.
There’s more than 100 AWS trainings on AI and Machine learning available to everyone. In addition, try out partyrock.aws and go through the getting started guide — let me know what you think!

Summary

I hope these developer events and course recommendations help spark some inspiration for you and your team throughout 2025. Let me know in the comments below what are your favorites worth checking out! 👇 💬

Stay connected
Stay up to date with Amazon Appstore developer updates on the following platforms:

📣 Follow @AmazonAppDev on Twitter
📺 Subscribe to our Youtube channel
📧 Sign up for the Developer Newsletter

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 ⬇️

Testing the startup time for your Fire OS app

Moses Roth — Thu, 31 Oct 2024 17:53:47 +0000

The first time you start up an app is like the first time you meet someone. Is it love at first sight? Or do they have a stain on their shirt and bad body odor? It’s the same with an app, does it start up quickly and smoothly? Or does it have long loading times and crash? Your customers will expect your app to be fast and responsive, and the best way to demonstrate that is with a quick startup, so that your app always makes a good first impression.

The FireOS Performance Test will help you measure First Frame (Time to Initial Display) to test how fast your app will get up and running.

Set up

To get started you’ll need to:

Install Java 8 or above
Install Java Development Kit 17 or higher
Install Android Studio (with Android SDK (API Level 34))
Install Maven
- Hint: The instructions on Maven’s website can be a bit confounding, so:
  - If you’re on a Mac, use Homebrew to install it by running brew install maven in the terminal
  - If you’re on Windows, check out this blog post
Set up ADB
- Hint: If you’re on a Mac, this blog can help with the command not found: adb error

Install

Once you’ve done that, you can install the performance tester with these steps:

Clone the performance tester repository by running this command in the terminal:
```
git clone https://github.com/amazonappdev/fireos-perf-testing.git
```
Navigate to the project directory:
```
cd fireos-perf-testing
```
Build the project and create the JAR:
```
mvn clean install
```

Run the test

You can then run the test with the following steps:

Locate the ZIP file FOSTTIDPerfTesting-distribution.zip file in the 'jar' folder
Unzip it
Navigate to FOSTTIDPerfTesting-distribution > Input > APK folder
Copy the APK file you want to test into the APK folder
Rename the APK file Input.apk
In the terminal, navigate to the new FOSTTIDPerfTesting-distribution folder
```
`cd FOSTTIDPerfTesting-distribution`
```
Decide which kind of test you want to do:
- cool
- warm
- latency (which does both cool and warm tests)
Plug your device in to your computer (if you haven’t already) and select "Allow USB Debugging" (if you haven’t already)
- Be sure that ADB has been set up correctly
Get your device serial number (if you don’t already have it on hand) by running
```
`adb devices`
```

Run the test with this command:

java -jar PerformanceKpi-jar.jar <Test Type> <Device Serial Number)>

If you decide to go with the full latency command, it should look something like this:

java -jar PerformanceKpi-jar.jar latency GCC2DM000000000S

The full latency test can take about an hour to run, so be patient!
You’ll find the test results in a folder called test-output in the FOSTTIDPerfTesting-distribution folder.

That’s all there is to it!

For more details, check out the github repo for the FireOS Performance Test. And if you want to dig even deeper into tests you can do on your app, check out the App Health Insights Dashboard, where you can test app latency, memory use, fluidity, and stability.

If you have any questions or feedback, join us in the the Amazon Appstore Community Space and let us know.

DEV Community: Amazon Developer

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+ 🎵

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

📰 February 2025 @AmazonAppDev Newsletter

From app submission to certification

Stay ahead of the trend

Recent updates

Developer highlights

Related resources

How does React Native's New Architecture affect performance?

What is the New architecture?

How can each pillar affect performance?

Testing Performance

Results

Average Results

Community Testing

Moving to the New architecture

📰 January 2025 @AmazonAppDev Newsletter

App performance

Inspect performance with the App Health Insights dashboard

Beyond "Hello World!"

Developer highlights

Related resources

Hello World for Fire TV with Kotlin & Jetpack Compose

Prerequisite

Light/Dark Mode

Navigation Drawer

Scrollable grid of cards

Conclusion

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