DEV Community: Anisha Malde

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

[Boost]

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

Danny

Aug 11 '25

React Native Web with Vite

#vite #reactnative #react #storybook

Comments

8 min read

The hidden costs in your package.json

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

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

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

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

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

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

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

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

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

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

Wait — waat?

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

import * from 'library'

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

At this point your probably still like:

Okay, So?

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

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

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

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

Checklist for adding a library

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

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

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

An Android Developer's Guide to React Native

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

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

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

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

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

Thinking in React vs Android

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

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

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

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

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

If we were to loosely bridge our Mental Model:

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

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

A typical React Native project structure could look like this:

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

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

UI: Components, Layout and Styling

Component Mental Model

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

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

Layouts

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

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

Styling

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

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

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

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

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

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

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

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

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

State

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

Core State Components - Props, Hooks and Context

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

In the Android world, props are similar to:

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

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

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

Core State Concepts

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

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

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

Component Lifecycle

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

Navigation

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

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

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

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

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

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

Business Logic

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

In Android Development

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

In React Native Development

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

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

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

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

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

Further Learning

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

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

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

How does React Native's New Architecture affect performance?

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

What is the New architecture?

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

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

How can each pillar affect performance?

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

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

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

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

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

Testing Performance

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

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

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

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

Results

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

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

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

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

Old Architecture

New Architecture

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

Average Results

Community Testing

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

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

Moving to the New architecture

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

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

How does React Native’s New Architecture affect performance?

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

What is the New architecture?

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

How can each pillar affect performance?

Testing Performance

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

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

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

Results

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

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

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

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

Old Architecture

New Architecture

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

Community Testing

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

Moving to the New architecture

My React(Native) New Years Resolutions

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

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

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

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

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

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

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

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

(For all my React Native TV developers)

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

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

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

What are your Re(act)solutions?

How to develop a React Native TV App

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

By Anisha Malde & Karol Latusek

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

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

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

Expo or Bare React Native?

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

Building a TV App With Expo

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

How to get started

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

Building a TV App With Bare React Native

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

How to get started

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

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

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

Adding TV Support to an Existing Project

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

1. Update package.json dependencies

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

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

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

2. Update Android Manifest

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

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

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

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

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

Declare that your app is built for Android TV:

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

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

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

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

3. Update Project.pbxproj

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

4. Update Podfile

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

This ensures your project is being configured for tvOS.

Structuring Your App to Handle the Additional TV Platform

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

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

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

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

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

Journeying from React to React Native: Differences & Similarities

Anisha Malde — Thu, 03 Oct 2024 10:15:12 +0000

As a React / JS developer, you’ve probably had the thought: "Should I learn React Native?"

It’s a fair question and one I asked myself a few years ago. Turns out, learning React Native was definitely the right decision. It's what landed me my role as a Sr. Developer Advocate @ Amazon, where I now use React Native to build apps across Android, Fire TV & Fire Tablet devices.

If you’re debating whether to make the jump beyond web apps, here are some thoughts on:

Why learn React Native?

The learn once, write anywhere philosophy extends beyond just iOS and Android – it now includes platforms like tvOS, VisionOS, and even desktop environments like react-native-macos
Industry relevance: Major companies like Amazon, Meta, and Microsoft are all adopting React Native. Why? Code reusability, cost effective and it allows you to build cross platform.
Strong community support: React Native has over 100k stars and 24k forks on GitHub, with regular updates and active development.
High developer satisfaction: According to the State of React Native Survey, 90% of developers would use React Native again!
Unified ecosystem: The React Native community rallies around Expo, leading to faster improvements, well-integrated third-party libraries, and abundant shared resources.

Familiar developer experience

React vs React Native: Similarities & Differences

Architecture and Compiling

Similarities:

Both use a reconciliation process often referred to as the "virtual DOM." This process diffs one tree against another to determine which parts of the UI need updating. Due to this, they both support fast refresh, enabling you to see UI changes in real-time.

Differences:

React compiles to render in web browsers, leveraging the DOM and web APIs. Even when accessed via mobile browsers, it's still constrained by the browser's capabilities and limited access to native device features.

React Native, on the other hand compiles to native code, allowing direct access to platform-specific APIs and features. This means React Native apps can utilize device capabilities like camera access, push notifications, providing a native user experience. Due to this, it takes a different approach to its architecture, with whats called the "bridgeless" architecture, and instead of the DOM it has native components. It uses Turbo Native Module’s and leverages a JavaScript Interface (JSI) allowing for direct communication between JavaScript and native code. This architecture is new and you may hear the term ‘new architecture’ being thrown around. If you are interested in learning more I covered this in a previous article.

JSX and Hooks

Similarities

Both use JSX for describing the UI and support React hooks (useState, useEffect, etc.). This allows you to maintain a consistent coding style and state management approach across both libraries.

Components

Similarities

Both React and React Native follow a component-based architecture and components follow the same lifecycle methods under the hood.

Differences:

Component Imports: In React Native you import UI components from react-native, unlike React where HTML elements are globally available. This difference is actually one of my favourite things about React Native as you have access to a set of pre-built components out of the box e.g. View, Text, Image, TextInput, ScrollView.
Platform-Specific Components: React Native also offers components and API's tailored for iOS and Android out of the box.
Text Handling: In React Native, all text must be wrapped in a <Text> component, unlike in React where text can be placed directly in many elements. This ensures proper styling and behaviour of text across different platforms, improving consistency and accessibility.
Event Handling: React uses onClick for click events, while React Native uses onPress for touch interactions, reflecting the different nature of interactions.

Styling

Similarities

Both React and React Native offer flexible approaches to styling components. They both support inline styling, allowing you to apply styles directly to components. Additionally, both enable the creation of reusable style objects.

Differences

Styling Language: React typically uses CSS or CSS-in-JS libraries for styling whereas React Native uses a JavaScript object-based styling system with some differences:
- Property Names: React Native uses camelCase for property names (e.g., fontSize instead of font-size).
- Value Units: In React Native you don’t need units for properties like width, height, or fontSize, it automatically assumes dimensions are in density-independent pixels.
StyleSheet API: React Native provides a StyleSheet.create() method for creating style objects. This API improve’s performance by reducing the need to recreate style objects on each render.
Style Application: Unlike in React where class names can be used to apply styles, React Native applies styles directly to components using the style prop.
Limited CSS Subset: React Native only supports a subset of CSS properties, focusing on those that make sense for different layouts. This means some web-specific properties (like float) are not available, while others (like flex) might behave differently.

Libraries & Tooling

Similarities

React and React Native share many core libraries. You can use the same state management libraries like Redux, MobX, and data fetching libraries like Axios or the Fetch API.

Differences

Navigation: While in React you might typically using React Router for web navigation, React Native has its own React Navigation library. This is because React (Web) typically uses URL-based navigation, where different components are rendered based on the current URL path. Whereas React Native uses stack-based navigation, mimicking the native mobile app experience. Screens are ‘stacked’ on top of each other, with transitions pushing new screens onto the stack or ‘popping’ them off.

💡 Note: Remember to name your folder ‘Screens’ instead of ‘Pages’ when structuring your app.

Testing: concepts remain similar across both libraries, focusing on component rendering and event simulation, but the specific testing libraries differ. React uses the React Testing Library, while React Native you would use React Native Testing Library (RNTL), but don’t be put off as RNTL just provides light utility functions on top of React Test Renderer.

💡 Some React libraries may not be compatible with all React Native platforms due to DOM dependencies, however you can check the platform compatibility of all the libraries at: (https://reactnative.directory)

Bridging the Gap with Universal React Apps

If you're still on the fence, the rise of Universal React Apps is a really exciting space that is further closing the gap between React and React Native. Universal React libraries and tooling, usually powered by react-native-web enable you to create cross-platform applications that run on iOS, Android, and the Web all from a shared React Native codebase. This lets you share navigation, styling, state management, and business logic saving you time and effort while respecting the unique conventions of each device type.

So as the lines between DOM and Device continue to blur, embracing React Native opens doors to the exciting world of multi-platform app development!

If you are ready to get started check the comments for my favourite resources or comment with yours below ⬇️

5 Ways Of Managing Focus In React Native

Anisha Malde — Wed, 11 Sep 2024 11:28:47 +0000

When it comes to handling Focus Management in React Native for TV apps, developers may find themselves going through five familiar stages (of grief): 🫣 😡 🙏 😭 👍

Focus management is a unique challenge in TV application development, due to the fragmentation across TV platforms that has led to a variety of focus management techniques. Developers have been forced to create and adopt multiple strategies for managing focus, often juggling platform-specific solutions alongside cross-platform abstractions. The challenge of focus is not only ensuring that focus is handled correctly but handling the platform differences. Android TV and Apple's tvOS have distinct native focus engines which you can read more about in this article written by my colleague @hellonehha.

Originally, TV-specific docs and APIs were part of the main React Native documentation. Now, most TV-specific content has moved to the react-native-tvos project.

react-native-tvos

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

The react-native-tvos project is an open source package that provides additions and extensions to the core React Native framework, with a specific focus on supporting Apple TV and Android TV platforms. Most of the changes in this project are centered around handling focus-based navigation on a SmartTV using the D-Pad on the remote control. The project is maintained by (the incredible!) Doug Lowder and is commonly recommended as the primary way to handle focus management in React Native TV applications.

However, like many community-maintained projects, the react-native-tvos project has evolved based on the needs of developers, and there are now an multiple ways to handle focus. Lets explore the additional components and enhancements to existing components that react-native-tvos provides:

1. TVFocusGuideView

TVFocusGuideView provides support for Apple's UIFocusGuide API and is implemented in the same way for Android TV, to help ensure that focusable controls can be navigated to, even if they are not directly in line with other controls - As per react-native-tvos.

For example, here’s a grid of 10 Pressable components rendered inside a TVFocusGuideView component:

import { TVFocusGuideView } from 'react-native';

const TVFocusGuideViewExample = () => {
  const [focusedItem, setFocusedItem] = useState(null);

  const renderGridItem = number => (
    <Pressable
      style={[styles.gridItem, focusedItem === number && styles.focusedItem]}
      key={number}
      onFocus={() => setFocusedItem(number)}
      onBlur={() => setFocusedItem(null)}>
      <Text style={styles.gridItemText}>{number}</Text>
    </Pressable>
  );

  return (
    <>
      <Header headerText="Movies" />
      <TVFocusGuideView trapFocusLeft style={styles.grid}>
        {[1, 2, 3, 4, 5, 6, 7, 8, 9, 10].map(num => renderGridItem(num))}
      </TVFocusGuideView>
    </>
  );
};

TVFocusGuideView accepts a few props that help you handle focus:

destinations prop

<TVFocusGuideView destinations={[]}>

With TVFocusGuideView you can set an array of components to register as ‘destinations’ of the TVFocusGuideView. Lets look at our example:

Setting the destinations prop to be a Ref to item 8 (destinations={[item8Ref.current]}) causes the focus to move to item 8 when we initially navigate to the TVFocusGuideView.

trapFocus prop

<TVFocusGuideView trapFocusUp|trapFocusDown|trapFocusLeft|trapFocusRight  />

This prop ensures focus does not escape from the parent component for the given directions. This prop ensures focus does not escape from the parent component for the given directions. Lets look at our example:

With the trapFocusLeft prop you can no longer navigate Left out of the container

autofocus prop

 <TVFocusGuideView autoFocus />

When autofocus is set to true, the TVFocusGuideView will manage focus for you by redirecting the focus to the first focusable child. It also remembers the last focused child and redirects the focus to it on the subsequent visits. If this prop is used with the destinations prop, the component set by the destinations prop will take precedence. Lets look at our example:

Without this prop when we moved from the Header component to the TVFocusGuideView focus went to the nearest component - item 3 (as per Androids proximity based built-in focus engine)
With the autofocus prop it goes to item 1

2. Touchable

With the react-native-tvos, the Touchable component's ( TouchableWithoutFeedback, TouchableHighlight and TouchableOpacity) include additional code to detect focus changes and properly style the components when focused. It also ensures that the appropriate actions are triggered when the user interacts with the Touchable views using the TV remote control.

Specifically, the onFocus event is fired when the Touchable view gains focus, and the onBlur event is fired when the view loses focus. This enables you to apply unique styling or logic when the component is in the focused state that doesn’t come out of the box with core React Native.

Additionally the onPress method has been modified to be triggered when the user selects the Touchable by pressing the "select" button on the TV remote (the center button on the Apple TV remote or the center button on the Android TV D-Pad) and the onLongPress event is executed twice when the "select" button is held down for a certain duration.

3. Pressable

Like Touchable, the Pressable component been enhanced to allow it to accept the onFocus and onBlur props.
Similar to the ‘pressed’ state that is triggered when a user presses the component on a touchscreen, the react-native-tvos Pressable component introduces a focused state that becomes true when the component is focused on the TV screen.

Here’s an example when using the Pressable and Touchable components from React Native core and they do not accept / execute the onFocus and onBlur props:

Using the same Pressable and Touchable components from react-native-tvos they accept and execute the onFocus and onBlur props:

4. `hasTVPreferredFocus` prop

Some React Native components have the hasTVPreferredFocus prop, which helps you prioritise focus. If set to true, hasTVPreferredFocus will force the focus to that element. According to the React Native docs these are the current components that accept the prop:

However, if you are using react-native-tvOS, there are a lot more components that accept this prop:

<View hasTVPreferredFocus />
<Pressable hasTVPreferredFocus />
<TouchableHighlight hasTVPreferredFocus />
<TouchableOpacity hasTVPreferredFocus />
<TextInput hasTVPreferredFocus />
<Button hasTVPreferredFocus />
<TVFocusGuideView hasTVPreferredFocus />
<TouchableNativeFeedback hasTVPreferredFocus />
<TVTextScrollView hasTVPreferredFocus />
<TouchableWithoutFeedback hasTVPreferredFocus />

Lets look at an example:

Setting the hasTVPreferredFocus prop to true for Pressable 2 causes focus be on Pressable 2
Changing it to be true when we are on Pressable 3 causes focus to move to Pressable 3

5. `nextFocusDirection` prop

The nextFocusDirection prop designates the next Component to receive focus when the user navigates in the specified direction helping you handle focus navigation. When using react-native-tvos, this prop is accepted by the same components that accept the hasTVPreferredFocus prop (View, TouchableHighlight, Pressable, TouchableOpacity, TextInput, TVFocusGuideView, TouchableNativeFeedback, Button). Lets look at an example:

nextFocusDown={pressableRef3.current}
nextFocusRight={pressableRef5.current}>

Setting the nextFocusDown prop to Pressable 3 causes focus to move to Pressable 3 when the focus moves down
Setting the nextFocusRight prop to Pressable 5 causes focus to move to Pressable 5 when the focus moves right

Conclusion

When it comes to handling focus management, there is no one-size-fits-all solution for React Native TV apps. The approach ultimately depends on the specific needs and requirements of your project. While the react-native-tvos provides a useful cross-device abstractions, you may have to adopt platform-specific solutions to handle common fragmentation issues across SmartTV platforms.

Take the time to explore these various focus management solutions so that you can deliver an intuitive focus handling experience for your users, regardless of the SmartTV platform they are using.

Related resources

How to become an Amazon Developer

Anisha Malde — Mon, 29 Jul 2024 14:59:27 +0000

When I tell people I work at Amazon I usually get asked 2 questions:

Can I have a free Prime membership?
or, How can I become an Amazon Developer?

Unfortunately, there is no magical guide to the question they are really asking, which is: 'How can I get a job at Amazon?'. However, learning about the whole world of Amazon development (that doesn't actually require you to work at Amazon) definitely can't hurt your chances!

As a React Native Developer Advocate for Amazon Appstore, I've learned that being an "Amazon developer" can mean anything from creating apps for Amazon devices, to integrating cloud computing solutions. Amazon's ecosystem provides numerous paths for developers to explore, so, this article is a guide of the different opportunities and where to get started:

Amazon's Developer Ecosystem

1. Amazon Appstore

The Amazon Appstore is Amazon's equivalent of Google Play / Apple's App Store. It is used for distributing apps, primarily for the Amazon Fire devices e.g. Fire Tablet. To build Apps for Amazon Appstore you can use Java / Kotlin for native Android development or React Native / Flutter / other cross-platform frameworks.

To learn more how to become an Amazon Appstore developer:

Checkout out the developer portal
Experiment with samples on GitHub
Join the developer community
Watch tutorials on YouTube
Read our blog
Follow me and my Team (Gio, Chris, Neha, Olivia & Moses)

2. Amazon Web Services (AWS)

AWS is Amazon's cloud computing platform, offering over 200 fully featured services. You can use AWS for multiple things ranging from building scalable web apps to managing and orchestrating containerised applications!

To learn more on how to become an AWS developer:

Check out the developer portal
Get AWS certified (e.g., AWS Certified Developer - Associate)
Join the developer community

AWS Amplify

AWS includes, AWS Amplify which is a set of tools and services for building full-stack applications in iOS, Android, Flutter, Web, and React Native. Amplify allows you to rapidly develop and deploying full-stack web applications as well as build cross-platform mobile apps with integrated backend service. This means you can use AWS Amplify to build apps for Amazon Appstore!

To learn more on how to build Apps with AWS Amplify:

Watch how we (Appstore x Amplify) built, monetised, submitted, and scaled an app all in an hour here
Check out the developer portal
Join the developer community
Take a course

3. Alexa Skills Kit

Alexa Skills Kit (ASK) allows developers to create voice apps for Alexa-enabled devices.

To learn more on how to to become an Alexa developer:

Check out the developer portal

Hopefully this helps!

If you feel catfished by the article title and are interested in working directly for Amazon, you can check out our open roles here. Otherwise, do let me know which journey you are excited to take or are currently on ⬇️

From JS to Fire OS: React Native for Amazon Devices

Anisha Malde — Wed, 17 Jul 2024 10:12:49 +0000

React Native enables developers to build native apps for Amazon Fire OS devices using their existing JavaScript and React skills. Since Fire OS is based on the Android Open Source Project (AOSP), if you are already working with React Native you can easily target our devices without learning a new tech stack or maintaining separate codebases.

We recommend using the Expo framework to build React Native apps as it enables an easier and faster development experience. Follow along to see how to get up and running with React Native for both Fire Tablets and Fire TVs.

✅ Pre-requisites for this guide

Install the following:

Node.js: The JavaScript runtime environment
npm or Yarn: Package managers for JavaScript
Android Studio: the IDE used to compile and run your Fire OS apps locally

Configure Android Studio and its command-line tools:

Follow this guide to set your ANDROID_HOME environment variable
Install the following emulators from Android Studio’s virtual device manager:

For Tablet:	For TV:

📱 Building for Fire Tablets

In the terminal, create a new React Native project with the expo package installed:

npx create-expo-app FireTabletDemo --template blank

Running on Fire Tablet Emulator

List the available avds then launch the Android Tablet:

emulator -list-avds
emulator -avd name-of-your-tablet-emulator

Navigate to the project directory (e.g. FireTabletDemo) and run the app using npx:

cd FireTabletDemo
npx expo start -a

Your app is now running on the emulator using a local development server and Expo Go, without having to create the Android build.

Running on a physical tablet device:

Follow the instructions here to connect your tablet via adb. Afterwards, confirm it is available as a device:

adb devices -l

Navigate to the project directory then run a development build on your target device (e.g. KFTRWI)

cd FireTabletDemo
npx expo run:android -d [deviceName]

The development build will now install within the android directory:

📺 Building for Fire TVs

To build apps for Fire TVs with React Native you can follow a similar journey.

In a new directory, create a new React Native project with the expo, this time using the with-tv example:

npx create-expo-app FireTVDemo -e with-tv

Running on Android TV Emulator

Launch the Android TV emulator:

emulator -avd name-of-your-tv-emulator

Navigate to the project directory and run your app:

cd FireTVDemo
npx expo start -a

Similar to the Fire tablets, your app will run on the avd emulator without having to create the Android build:

Target the build for TVs:

In order to build for TVs, set the isTV prop to true in your app.json:

{
  "expo": {
    "plugins": [
      [
        "@react-native-tvos/config-tv",
        {
          "isTV": true,
        }
      ]
    ],
    "name": "FireTVDemo",
    "slug": "FireTVDemo"
  }
}

Running your project on a Fire TV device

To connect your Fire TV, follow the instructions here then check that your device is connected using adb:

adb devices -l

Navigate to the project directory then run a development build on your target device (e.g. -d AFTSS)

cd FireTVDemo
npx expo run:android -d [deviceName]

You now have the development build installed on your device:

💡 You can verify your android builds are optimized for TV by checking that your app is using the Android leanback features in the Android manifest file.

Next steps

Congratulations on building your first React Native app for Amazon Fire Devices! To continue your learning journey you can:

Sign up for an Amazon Developer account
Join the Amazon Developer community
Integrate Amazon APIs in your app

DEV Community: Anisha Malde

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

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

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

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

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

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

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

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

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

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

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

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

[Boost]

The hidden costs in your package.json

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

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

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

Wait — waat?

Okay, So?

Checklist for adding a library

An Android Developer's Guide to React Native

Thinking in React vs Android

UI: Components, Layout and Styling

Component Mental Model

Layouts

Styling

State

Core State Components - Props, Hooks and Context

Core State Concepts

Component Lifecycle

Navigation

Business Logic

Further Learning

How does React Native's New Architecture affect performance?

What is the New architecture?

How can each pillar affect performance?

Testing Performance

Results

Average Results

Community Testing

Moving to the New architecture

How does React Native’s New Architecture affect performance?

What is the New architecture?

How can each pillar affect performance?

Testing Performance

Community Testing

Moving to the New architecture

My React(Native) New Years Resolutions

How to develop a React Native TV App

By Anisha Malde & Karol Latusek

Expo or Bare React Native?

Building a TV App With Expo

How to get started

Building a TV App With Bare React Native

How to get started

Adding TV Support to an Existing Project

Structuring Your App to Handle the Additional TV Platform

Journeying from React to React Native: Differences & Similarities

Why learn React Native?

React vs React Native: Similarities & Differences

Architecture and Compiling

Similarities:

Differences:

JSX and Hooks

Similarities

Components

Similarities

Differences:

Styling

Similarities

Differences

Libraries & Tooling

Similarities

Differences

Bridging the Gap with Universal React Apps

5 Ways Of Managing Focus In React Native

1. TVFocusGuideView

destinations prop

trapFocus prop

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

4. `hasTVPreferredFocus` prop

5. `nextFocusDirection` prop