Trendspotting: Navigating Architectural Shifts in React Native

[0:00]Wasif: Welcome back to Stack Patterns, the show where we decode the architectural decisions behind today’s most impactful apps. I’m your host, Alex Rivera. Today, we’re diving deep into a topic that’s been shaking up mobile teams everywhere—React Native’s latest trends and architectural patterns. And to help us navigate this fast-evolving space, I’m joined by Priya Menon, Lead Mobile Architect at AppForge Labs. Priya, welcome to the show!

[0:24]Priya Menon: Hi Alex, thanks for having me! I’m excited to be here and honestly, React Native architecture is one of my favorite rabbit holes.

[0:40]Wasif: I love that. Before we get into the weeds, could you share a bit about your background? How did you get into mobile architecture, and what are you focused on nowadays?

[1:00]Priya Menon: Sure! I started out as a front-end developer, then jumped into mobile with React Native when it was still a bit of a wild west. Over time, I moved into architecture, mostly because I kept running into scaling headaches. At AppForge, I lead a team that maintains several large React Native apps—think fintech, logistics, some e-commerce. My day-to-day is all about keeping things modular, robust, and as future-proof as we can make them.

[1:45]Wasif: That’s a great segue. You said 'the wild west'—what’s changed since then? Why are people rethinking their React Native architecture now?

[2:20]Priya Menon: It comes down to maturity. Early on, React Native promised 'write once, run anywhere', but as apps grew, that simplicity vanished. Teams hit issues with performance, codebase bloat, and tangled navigation. Now, with more complex products, people want scalable patterns—hence the shift toward modularity and clearer architectural boundaries.

[3:30]Wasif: Let’s pause and define that for listeners. When you say 'modularity' in React Native, what do you mean?

[3:50]Priya Menon: Great question. Modularity is about breaking your app into isolated, reusable pieces—think of each feature or domain as its own module with minimal dependencies. This makes it easier to scale development, onboard new engineers, and even swap out components if one approach stops working.

[4:15]Wasif: So, is that just splitting components into folders, or is it deeper?

[4:28]Priya Menon: It’s deeper. The old way was just having a 'components' folder, maybe a 'screens' folder. Now, you’re seeing teams organize by feature—so everything related to, say, payments lives together: UI, business logic, API calls, even navigation entries. It’s like giving each feature its own little ecosystem.

[5:10]Wasif: Is there a trade-off there? Do you ever find it gets harder to coordinate between those feature modules?

[5:25]Priya Menon: Absolutely. The upside is independence, but the downside is duplication or unclear boundaries if you’re not disciplined. You need conventions and documentation, or else it’s chaos in a different flavor.

[6:10]Wasif: Let’s connect this to a real-world scenario. Can you share a story where moving to a modular structure made a big difference?

[6:32]Priya Menon: Sure! We worked with a logistics client whose app ballooned to over a hundred screens. Originally, everything was jammed together. When a new compliance feature was needed, it broke existing flows. After refactoring to a modular structure—where compliance was its own module—the team could build and test changes in isolation. Deployments got faster, and onboarding new devs became almost painless.

[7:20]Wasif: That’s a huge win. Are there cases where modularity isn’t worth it?

[7:35]Priya Menon: If your app is small—maybe a dozen screens—you might not need the overhead. But as soon as multiple teams touch different parts or you plan to scale, it pays off to invest in modularity early.

[8:30]Wasif: Now, there’s a buzz about micro-frontends, which started on web. Are people really doing this in mobile React Native?

[8:52]Priya Menon: It’s catching on, especially in big orgs. The idea is to let different teams own, deploy, and even version their own app sections independently. In React Native, it’s trickier—there’s more to coordinate with navigation and shared state—but we’re seeing tools and patterns emerge to make it possible.

[9:20]Wasif: What’s the main challenge with micro-frontends on mobile?

[9:36]Priya Menon: Isolation. On the web, you can load micro-apps via iframes or dynamic imports. In React Native, you have to think about shared dependencies, navigation hand-offs, and making sure your bundle size doesn’t explode. Not every team is ready to handle that complexity.

[10:30]Wasif: Let’s do a quick case study. Have you seen a team successfully pull off micro-frontends in React Native?

[10:52]Priya Menon: We worked with a fintech company that wanted fast releases for their rewards program, separate from core banking. They split out rewards into a separate package, with its own release cadence. It took a lot of architectural discipline—shared contracts, strict versioning—but it let them experiment without risking banking flows. Not trivial, but the payoff was real agility.

[11:40]Wasif: It sounds like micro-frontends give you speed but need a lot of guardrails. Would you agree?

[11:55]Priya Menon: Yes, absolutely. Without contracts and coordination, you end up with duplicated logic and hard-to-debug bugs. But with the right foundation, it can unlock big scaling wins.

[12:40]Wasif: Switching gears: Code sharing. Some teams want a single codebase for web and mobile. How feasible is that in React Native now?

[13:00]Priya Menon: It’s more possible than ever, thanks to libraries like React Native Web. But you have to be realistic. UI patterns, navigation, and even data fetching often diverge. I tell teams: share business logic, but don’t force UI reuse unless the user experience truly aligns.

[13:40]Wasif: So, where do you draw the line on code sharing? Any practical examples?

[14:00]Priya Menon: We once tried sharing almost everything for an e-commerce app. It backfired when web and mobile needed different checkout flows. Now, we share things like validation logic and API calls, but keep UI and navigation separate. It’s about finding the right balance.

[14:40]Wasif: What about monorepos? Are they the answer for teams juggling multiple apps and packages?

[15:00]Priya Menon: Monorepos help with consistency and sharing code, but they also introduce complexity. You need proper tooling for builds, dependency management, and CI. If you’re not careful, a monorepo can turn into a bottleneck rather than a productivity boost.

[15:30]Wasif: Can you give an example of monorepo pain points?

[15:46]Priya Menon: Absolutely. At one point, we had a monorepo with five React Native apps and several shared packages. When we upgraded dependencies in one app, it broke others. Our CI pipelines got slow and flaky. It forced us to set up better versioning and isolate changes, but it was a painful lesson.

[16:40]Wasif: So, monorepos can be great—if you’re disciplined. Let’s move to navigation. What’s trending there?

[17:00]Priya Menon: Navigation is evolving. Most teams start with stack and tab navigation, but as apps grow, they need nested navigators, deep linking, and custom flows. There’s a push towards declarative navigation and more type-safe patterns, especially in larger apps.

[18:10]Wasif: What’s a common mistake teams make with navigation architecture?

[18:28]Priya Menon: Relying on a single global navigator and stuffing all routes into it. This makes refactoring a nightmare. A better path is to scope navigation to features and compose them, so you can change flows independently.

[19:10]Wasif: Let’s talk state management. Redux used to be the default; is that still true?

[19:30]Priya Menon: It’s less universal now. Context works for simple cases, and libraries like Recoil or Zustand are gaining traction. Redux is still great for complex, shared state—especially if you need time-travel debugging or middleware—but it’s no longer a one-size-fits-all.

[20:10]Wasif: How do you pick the right state tool for a new React Native project?

[20:27]Priya Menon: Start small. Use Context for local state. If you notice a lot of prop drilling or tangled logic, consider Redux or another state lib. The key is to avoid premature optimization—over-architecting state leads to confusion.

[21:00]Wasif: Can you share a cautionary tale about state management going sideways?

[21:20]Priya Menon: Definitely. On a past project, we set up Redux for everything—loading states, modals, form fields. It became so bloated that onboarding new engineers was overwhelming. Eventually, we moved most of that state into local component state or Context, and things got much simpler.

[22:00]Wasif: So, more isn’t always better. Are there cases where you’d push back against Redux or global state?

[22:15]Priya Menon: Absolutely. If the state doesn’t need to be shared across features, keep it local. Use global state sparingly—for authentication, user profiles, or things that genuinely cross boundaries.

[23:10]Wasif: Let’s recap for listeners: modular architecture, careful code sharing, and scoped navigation and state—that’s the emerging playbook?

[23:25]Priya Menon: That’s right. There’s no silver bullet, but these patterns help teams avoid the chaos that hits as apps grow.

[24:00]Wasif: Before we move on, I want to ask about dependency injection. It’s huge in native mobile, but rarely discussed in React Native. Where does it fit?

[24:18]Priya Menon: It’s starting to gain ground. As apps modularize, you want to inject dependencies—like analytics, API clients, or feature flags—rather than hard-coding them. Libraries like Inversify or even simple context providers can help, but it’s still an emerging area.

[25:00]Wasif: Any practical advice for teams wanting to adopt dependency injection?

[25:20]Priya Menon: Start by creating interfaces for your dependencies, and use providers to inject them where needed. It helps with testing and swapping out implementations—say, a mock analytics service in development. But don’t overcomplicate it; only abstract what you need.

[25:50]Wasif: Let’s do a quick rapid-fire: what’s one architectural decision you wish more teams would revisit in React Native?

[26:05]Priya Menon: I’d say navigation. Teams underestimate how tightly it couples features together. Rethinking navigation early saves so many headaches later.

[26:30]Wasif: Now, I want to play devil’s advocate. Some devs say all this modularity and DI is overkill for most apps. Thoughts?

[26:48]Priya Menon: I get it. If you’re shipping a side project or MVP, keep it simple. But for anything with a roadmap or multiple contributors, investing in architecture pays dividends. I’ve seen too many teams hit the wall at scale.

[27:30]Wasif: I appreciate the nuance there. It’s about matching architecture to context. Priya, we’ll pause here. When we come back, let’s tackle bundle size, native modules, and some real-world production war stories. Stay tuned!

[27:30]Wasif: Alright, welcome back! We’ve been digging into the latest trends and architectural patterns in React Native. Now, let’s shift gears a bit—let’s talk about code sharing. This comes up constantly with teams I speak to. How are modern teams actually achieving robust code sharing between web and mobile using React Native today?

[27:55]Priya Menon: That’s a hot topic, for sure. One thing we’re seeing is the rise of monorepos with packages that encapsulate shared business logic. Teams are using tools like Nx or Turborepo to structure their codebases, so core logic is reusable across React Native and React web. But UI components often need a bit of platform-specific tweaking.

[28:20]Wasif: So, you’re saying business logic is the easy part, but the UI is trickier—why is that?

[28:38]Priya Menon: Exactly. Even though React and React Native share similar paradigms, the platforms have different primitives—like div versus View, and web-specific style issues. Sometimes you can use libraries like react-native-web to bridge the gap, but for complex animations or gestures, you’ll still need platform-specific code. It’s about striking a balance without over-abstracting.

[29:00]Wasif: Interesting. Before we go deeper, can you share a quick anonymized case study—maybe a team that tried code sharing and hit some bumps?

[29:25]Priya Menon: Absolutely. There’s a fintech company I worked with. They wanted a single codebase for their customer portal on web and mobile. It worked well for shared utils and business logic, but their onboarding flow looked ‘off’ on mobile because it was designed for web first. They had to split the UI layer and keep shared logic in a package. The takeaway: code sharing works best for non-UI code, and you shouldn’t force it where it doesn’t fit.

[29:55]Wasif: That’s a great lesson. Now, shifting to architecture, what are your thoughts on state management today? Redux used to be everywhere, but now there are so many choices—Recoil, Zustand, Jotai, even plain Context. What’s working in production React Native apps now?

[30:22]Priya Menon: Redux is still around for huge, complex apps, but modern teams seem to prefer lighter-weight solutions. Zustand and Jotai are increasingly popular because they're simple, have low boilerplate, and play nicely with React Native’s reactivity. Context is fine for small scope, but gets cumbersome at scale. The key is to avoid over-engineering—pick what matches your app's complexity.

[30:44]Wasif: Totally. Can you share a story where state management decisions made or broke a project?

[31:05]Priya Menon: Sure. There was a social media app where the devs chose Context for everything—user auth, feeds, notifications. As the app grew, they ran into performance bottlenecks and hard-to-maintain code. Eventually, they refactored to Zustand for local state and Redux for global state, which improved maintainability and performance.

[31:27]Wasif: Let’s talk navigation. React Navigation is kind of the de-facto, but there’s also React Native Navigation, and even Expo Router now. How are people choosing between them?

[31:50]Priya Menon: Most teams stick with React Navigation because it’s flexible and community-supported. React Native Navigation gives a more native feel, but it’s heavier and less flexible for cross-platform features. Expo Router is gaining traction for those in the Expo ecosystem—it makes routing feel more like Next.js. Ultimately, it comes down to your app’s needs—if you need deep native integrations, React Native Navigation is worth the trade-off.

[32:15]Wasif: And what about performance? Are there common mistakes teams make that tank their app’s speed or responsiveness?

[32:39]Priya Menon: Definitely. The biggest mistake is over-rendering—passing too many props, or not using FlatList for big lists. Also, not memoizing heavy components. I’ve seen apps where every keystroke triggered a full re-render of the screen. Profiling tools are your friend—use them early and often.

[33:03]Wasif: That’s a classic. Now, let’s go rapid-fire! I’ll throw out a trend or pattern, you give me a quick take. Ready?

[33:05]Priya Menon: Let’s do it!

[33:07]Wasif: Expo or bare React Native?

[33:10]Priya Menon: Start with Expo for most projects—eject only if you hit a wall.

[33:13]Wasif: TypeScript—must-have or nice-to-have?

[33:16]Priya Menon: Must-have. Saves time and bugs in the long run.

[33:18]Wasif: Component libraries: use or roll your own?

[33:21]Priya Menon: Use established ones for core UI—customize only where you need to stand out.

[33:23]Wasif: Animations—Reanimated or Animated API?

[33:26]Priya Menon: Reanimated for anything complex. Animated API for simple stuff.

[33:29]Wasif: Third-party native modules—risk or reward?

[33:32]Priya Menon: Reward if well-maintained, risk if abandoned—always check the repo activity.

[33:35]Wasif: Testing: E2E or unit first?

[33:38]Priya Menon: Start with unit, add E2E for core flows. Both matter.

[33:40]Wasif: Last one—dark mode: built-in or custom?

[33:43]Priya Menon: Use built-in Appearance API unless you need advanced theming.

[33:47]Wasif: Love it! Thanks for playing. Now, let’s get into modularization. How are teams structuring their code so that features don’t become tangled spaghetti?

[34:10]Priya Menon: Feature-based folder structures are big right now. Each feature—like authentication or chat—gets its own directory, with its own components, hooks, and even tests. Some teams split core and feature modules, using tools like Lerna or Nx to enforce boundaries. This keeps teams moving fast without stepping on each other’s toes.

[34:32]Wasif: Do you have an example where modularization saved a project?

[34:48]Priya Menon: Yes! A healthtech startup I helped had a sprawling codebase. They moved to a feature-module approach and saw onboarding time for new devs drop by half—because everything was discoverable, and teams could own features end-to-end.

[35:06]Wasif: That’s powerful. Now, what about dependency management? Any pitfalls React Native teams should watch out for?

[35:26]Priya Menon: Absolutely. Native dependencies can be a headache, especially with mismatched versions. Stick to well-supported libraries, and lock your dependency versions. Regularly audit for abandoned packages. And don’t forget to test on real devices—simulators don’t catch every native edge case.

[35:47]Wasif: Let’s double-click on the topic of CI/CD. What are best practices for setting up a robust pipeline for React Native?

[36:08]Priya Menon: Automate as much as possible. Use services like GitHub Actions, Bitrise, or CircleCI. Run linting, unit tests, and build both platforms on every commit. Automate app store deployments if you can. And always sign builds securely—leaked keys are a nightmare.

[36:29]Wasif: Are there any common mistakes that teams make with CI/CD in React Native?

[36:48]Priya Menon: Yes—skipping tests to speed up builds, or not caching dependencies correctly. Also, not testing release builds—debug builds can hide issues. And forgetting to run E2E tests on real devices; emulators don’t always behave the same.

[37:07]Wasif: Let’s turn to native modules. What are the pros and cons of writing your own versus using community packages?

[37:29]Priya Menon: Writing your own gives control, but it’s time-consuming and requires native expertise. Community packages are faster to adopt, but can introduce risk if under-maintained or poorly documented. For unique hardware features, you may have no choice but to build custom.

[37:51]Wasif: What about the migration story? When Expo managed workflow hits a wall—what should teams watch for when ejecting?

[38:14]Priya Menon: Ejecting is sometimes necessary, but it’s a one-way street. Teams should make sure all dependencies are compatible with bare React Native. Prepare for more native code, and have someone on the team who understands Xcode and Android Studio. And always backup your code before ejecting!

[38:35]Wasif: Let’s talk about OTA updates. Are teams actually using CodePush or Expo Updates in production?

[38:54]Priya Menon: Absolutely. OTA updates let you fix bugs and push improvements without waiting for app store reviews. But you have to be careful—don’t update anything that touches native code, or you’ll risk crashes. Always test OTA updates thoroughly.

[39:14]Wasif: Are there any gotchas with OTA updates you’ve seen in the wild?

[39:36]Priya Menon: Definitely. I’ve seen apps break because an OTA update expected a new native API, but the app binary was still old on some devices. This led to crashes for users who hadn’t updated through the store yet. The lesson: never update JS that relies on new native code via OTA until you’re sure everyone’s updated the binary.

[39:55]Wasif: Great advice. Now, I want to touch on testing strategies. How deep are teams going with testing React Native apps these days?

[40:19]Priya Menon: Modern teams do a mix of unit tests, integration tests, and E2E. Jest is still the go-to for unit tests, while Detox or Maestro are popular for E2E. Snapshot tests help catch UI regressions. The key is to automate as much as possible and focus on critical user flows.

[40:39]Wasif: What’s the most common gap you see in React Native test coverage?

[40:56]Priya Menon: E2E coverage is often lacking. Teams focus on unit tests but skip real-device flows—so they miss issues with navigation, permissions, or device-specific bugs. Those are the bugs that actually hit users.

[41:14]Wasif: Let’s pivot to accessibility. How are teams approaching accessibility in React Native now?

[41:36]Priya Menon: It’s getting more attention, but still not where it should be. Teams are using props like accessible, accessibilityLabel, and testing with screen readers. There are also libraries to help, but manual testing is still crucial. The earlier you think about accessibility, the less rework you’ll have.

[41:54]Wasif: Any practical steps for teams just starting with accessibility?

[42:15]Priya Menon: Start by using accessibility props everywhere—labels, roles, hints. Test with real screen readers on iOS and Android. And get feedback from users with disabilities if possible. Accessibility isn’t a checkbox—it’s an ongoing process.

[42:34]Wasif: Let’s circle back to performance. What are your go-to tools for profiling and finding bottlenecks in React Native?

[42:56]Priya Menon: React DevTools for JS profiling, Flipper for native debugging, and the built-in performance monitors. Also, Android Studio and Xcode instruments for deep dives. Sometimes, just logging render counts helps you spot unnecessary renders.

[43:14]Wasif: What’s the biggest performance mistake you’ve seen in a live app?

[43:32]Priya Menon: A retail app loaded a giant product catalog all at once, instead of paginating. The app crashed on low-end devices—users just couldn’t shop. Switching to FlatList with pagination fixed it.

[43:50]Wasif: Let’s get into design systems. Are teams building them in React Native, or just using whatever’s available off the shelf?

[44:11]Priya Menon: A bit of both. Mature teams invest in shared design systems—tokens, typography, colors—sometimes shared with web. Others start with UI libraries like React Native Paper, then customize. The key is consistency and reusability, whether you roll your own or not.

[44:30]Wasif: What’s a pitfall with design systems in React Native?

[44:48]Priya Menon: Trying to mirror web too closely. Mobile has different constraints—touch targets, gestures, screen sizes. Overly generic design systems end up being ignored or hacked around.

[45:04]Wasif: Let’s talk security. How should teams handle secrets and sensitive data in React Native apps?

[45:24]Priya Menon: Never hard-code secrets. Use secure storage modules for sensitive data, and keep environment variables out of your JS bundle. Protect against reverse engineering—obfuscate code, and use server-side validation for critical business logic.

[45:42]Wasif: Now, there’s always the question of app size. Any tips for keeping React Native apps lean?

[46:03]Priya Menon: Audit your dependencies—don’t ship huge libraries for one function. Use Hermes on Android for smaller JS bundles and faster startup. Optimize image assets, and enable Proguard to strip unused code. Every MB counts.

[46:22]Wasif: Let’s do one last anonymized case study—can you share a story where React Native’s flexibility made a real impact?

[46:47]Priya Menon: Sure! A logistics company I worked with needed to pivot features rapidly as regulations changed. Because their codebase used React Native, they could push updates to both platforms quickly, and even use OTA updates for non-native changes. Their competitors, on separate native stacks, took weeks longer to ship the same changes.

[47:08]Wasif: That’s a great story. Now, before we wrap, let’s give listeners an actionable checklist. What’s your ultimate React Native implementation checklist?

[47:20]Priya Menon: Absolutely. Here’s what I recommend:

[47:25]Priya Menon: • Start with clear requirements for both platforms.

[47:28]Priya Menon: • Choose Expo unless you need deep native features.

[47:31]Priya Menon: • Set up a monorepo for shared logic.

[47:33]Priya Menon: • Pick the right state management tool for your app’s size.

[47:36]Priya Menon: • Use feature-based modularization.

[47:39]Priya Menon: • Automate CI/CD with testing and builds for both platforms.

[47:42]Priya Menon: • Use OTA updates responsibly—never update JS that depends on new native code.

[47:45]Priya Menon: • Prioritize accessibility from day one.

[47:47]Priya Menon: • Profile and optimize performance early.

[47:50]Priya Menon: • Regularly audit dependencies and security.

[47:54]Wasif: Such a useful rundown. If someone’s starting out or modernizing an app, do you have any final words of wisdom?

[48:11]Priya Menon: Don’t chase every trend—focus on fundamentals, ship iteratively, and plan for scale but don’t over-engineer from day one. And always test on real devices!

[48:28]Wasif: Awesome. We’re almost out of time, so let’s hit some closing thoughts. What excites you most about the future of React Native?

[48:45]Priya Menon: The community’s constant innovation. There are new libraries, better tooling, and more companies betting on React Native for serious products. The ecosystem’s only getting stronger.

[49:00]Wasif: And what’s one area you think still needs work?

[49:15]Priya Menon: Better out-of-the-box support for new native APIs. Sometimes it still lags behind, so you need to write your own bridges. But it’s improving fast.

[49:30]Wasif: Before we sign off, any recommended resources for listeners who want to go deeper?

[49:48]Priya Menon: Definitely. Check out the React Native docs, the Expo blog, and community forums like Stack Overflow and Reactiflux Discord. For architecture, look up the official guides and some real-world open-source apps on GitHub.

[50:05]Wasif: Great tips. For our listeners, we’ll link those in the show notes. Any parting advice for teams debating React Native versus pure native development?

[50:26]Priya Menon: Weigh your needs—if you need the absolute latest native APIs, native may be better. But for most business apps, React Native delivers faster iteration and great user experience. Start simple, and you can always go deeper into native if you hit limitations.

[50:47]Wasif: Thanks for such an insightful conversation! To summarize, we’ve covered code sharing, modularization, state management, navigation, testing, CI/CD, performance, accessibility, security, and more. Any last thoughts?

[51:03]Priya Menon: Just that React Native is more mature and flexible than ever. With the right patterns and a strong team, you can build anything—from MVPs to complex, production-grade apps.

[51:15]Wasif: Alright, let’s end with a quick recap checklist for our listeners:

[51:18]Wasif: • Don’t overcomplicate state management.

[51:20]Wasif: • Modularize your code early.

[51:22]Wasif: • Test on real devices, not just emulators.

[51:24]Wasif: • Leverage CI/CD for reliable builds.

[51:27]Wasif: • Invest in accessibility and performance from day one.

[51:30]Wasif: Alright, that’s a wrap. Thanks so much for joining us and sharing your expertise!

[51:36]Priya Menon: Thanks for having me—this was a blast!

[51:40]Wasif: And thanks to everyone listening. If you enjoyed this episode, subscribe, leave a review, and check out our other episodes on the latest in app development.

[51:48]Wasif: For more resources and links, see the show notes. We’ll catch you next time on Softaims!

[51:54]Priya Menon: Take care, everyone!

[52:00]Wasif: Bye for now.

[52:10]Wasif: —

[52:18]Wasif: If you’re still with us, here’s a bonus: what’s an underrated React Native pattern you wish more teams used?

[52:32]Priya Menon: Dependency injection with hooks. It’s a clean way to inject services and swap implementations—great for testing and modularity.

[52:44]Wasif: Nice! And any thoughts on backend integration patterns—should teams go REST, GraphQL, or something else?

[52:59]Priya Menon: GraphQL is popular for flexibility, but REST is simpler for small projects. Don’t overcomplicate—match your backend to your frontend’s real needs.

[53:09]Wasif: Wise words. Okay, we’re really out now. Thanks again!

[53:13]Priya Menon: Thank you! Always a pleasure.

[53:20]Wasif: Signing off from Softaims—keep building, keep learning!

[53:25]Wasif: —

[53:30]Wasif: If you have feedback or want to suggest topics, drop us a line. Until next time, happy coding!

[53:35]Priya Menon: Goodbye!

[53:40]Wasif: This has been Softaims. See you soon.

[53:45]Wasif: —

[54:00]Wasif: And that’s a wrap. Final sign-off—thanks for listening. Stay tuned for more.

[54:05]Wasif: Softaims out.

[54:10]Priya Menon: All the best!

[54:14]Wasif: Take care.

[54:30]Wasif: Ending recording in 3… 2… 1.

[55:00]Wasif: —