Notes on React Native for Windows and web wrapper frameworks for Windows Desktop like Electron - ChatGPT

Last updated on 7 Sep. 2025

Contents

=========================================

Section Summaries

1. React Native for Windows (and macOS)

React Native for Windows (and macOS) is maintained by Microsoft. It lets you write React Native code that runs as a native app on Windows (via UWP or Win32 under the hood). It’s not as battle-tested as React Native for Android/iOS, but it’s steadily improving and is used in production by Microsoft apps (like the Xbox app and some Office components).
-----------

2. "Web Wrapped" Windows Desktop App

A "web wrapped" Windows app is a web app is placed inside a native desktop shell so it can run as a standalone Windows program. The shell is usually Chromium (via Electron) or WebView2 (via Microsoft Edge). To the user, it looks like a Windows app (.exe) but internally, it’s just showing your web app.

Summary Table of Web-based desktop applications—especially for Windows

Framewrk PopulartyApp SizePerformanceLanguage RequirementBest For
Electron Very high Large   (~100+ MB) Good JavaScript/Node.jsSpeedy dev +  massive ecosystem
Tauri Growing Tiny (~2–10   MB) High &   efficient Rust (backend) + JS/HTML Lightweight apps  with tighter UX
Neutralino Niche Tiny Similar to Tauri Pure JS front &   backendUltra-light apps,  minimal tools

For Windows, Electron remains the dominant choice—trusted, reliable, and widely supported. However, Tauri is emerging fast as the modern alternative for those who prioritize performance, security, and small bundle size.

PWA is another option for publishing a React app as Desktop Windows app. It can be submitted to Microsoft Store.

-----------------------

3. Performance Comparison between React Native Windows and Electron/Tauri/PWA

  1. Electron/Tauri/PWA
    • Render in a browser engine (Chromium/WebView2).
    • Every button, view, and animation is drawn by the browser.
  2. React Native for Windows
    • UI is rendered by native Windows components.
    • It’s closer to a “real Windows app.”
    • No Chromium overhead (no HTML/CSS layout engine).
This means React Native for Windows can have better performance, especially for:
  • UI rendering (native controls are usually more efficient than browser DOM).
  • Memory usage (no full Chromium instance).
But disadvantages of React Native for Windows are:
  • You need to actually build & maintain a separate Windows version of your app.
  • Your existing React Native + Expo code will not 100% work out-of-the-box — you may need platform-specific tweaks.
  • React Native for Windows is solid but not as battle-tested as React Native for iOS/Android.
  • Some Expo APIs may not be supported yet.
-------------------------------

4. Porting/Upgrading React Native and Expo for Web app to React Native for Windows (Desktop app)

  • Looks like Expo is the big tripping up point as Expo does not seem to have support for Windows platform.
  • React Native without Expo project could have better chances of easier port/upgrade to support Windows platform.
===================================================================
===================================================================

Details

Extracts from chat with ChatGPT (CG) on or around 27 Aug 2025, spread across two chats, 'React Native and Expo vs React PWA/Web' and 'React Native for Windows; Web Dev Arch' are given below.

Section 1. React Native for Windows (and macOS)

Me: Just for discussion and learning and not for any immediate implementation, I am asking the following. I believe there is a React Native for Windows library too though it may not be mature. If I wanted to, for my Timestamp Tracker app, I could explore using React Native for Windows library to create a Native app for Windows OS which could roughly have similar advantages to Web version on Windows, as Native Android app has when compared to Web on mobile.

Note that WhatsApp provides (Native) Android app, web app as well as (Native) Windows app. I use the Android version on my mobile and use the web version on my Windows PC with the latter being good enough for my needs. But I know that if I want to explore some slightly better functionality on my Windows PC, I could use WhatsApp Native Windows app. My above question is somewhat related to what I have said now about WhatsApp.

...
CG: Yes, you’re right — there is a React Native for Windows (and macOS) maintained by Microsoft. It lets you write React Native code that runs as a native app on Windows (via UWP or Win32 under the hood). It’s not as battle-tested as React Native for Android/iOS, but it’s steadily improving and is used in production by Microsoft apps (like the Xbox app and some Office components).

...
Me: It is truly fascinating to know of the possibility of using my same source code base of Timestamp Tracker app with perhaps some platform specific tweaks and some build tool effort, to have a Native Windows app (or MacOS app). I think that vision is awesome!
...
CG: Exactly 🙌 — that’s one of the most powerful parts of the React Native ecosystem: the “learn once, write anywhere” vision.

With your Timestamp Tracker app, here’s how that awesome vision plays out:

  • Single Source of Truth → Your core logic (timestamp creation, storage, dark mode, export-to-file, etc.) stays the same across Android, iOS, Web, Windows, macOS.

  • Platform-Specific Tweaks → You sprinkle in platform-specific code only where it’s truly needed:

    • Mobile → touch gestures, Android/iOS status bar handling.

    • Web → keyboard shortcuts, maybe export as downloadable file.

    • Windows/macOS → system tray icon, notifications, OS file picker.

  • Build Tooling → Instead of rewriting apps in Java/Kotlin (Android), Swift/Obj-C (iOS), WPF/UWP (Windows), or Electron (desktop), you leverage the same React Native foundation with platform bridges.

...

Me: Tell me more about WhatsApp dev strategy for its various platform apps.
...
[CG provided a longish response to which I responded with a summary and asked if my summary was correct.]
CG: Yes 👍 your summary is right on target:

  1. Fully native mobile apps (Android/iOS)

    • WhatsApp uses separate native stacks (Java/Kotlin for Android, Swift for iOS).

    • Essentially no real code sharing between these and the web/desktop apps.

    • Chosen for performance, deep OS integration, and reliability.

  2. Web app + desktop wrappers

    • WhatsApp Web is the core shared codebase (JavaScript/HTML/CSS).

    • Desktop apps (Electron earlier, now WebView2 wrapper) re-use this web codebase almost fully.

    • Not “fully native” on Windows/macOS — more like a packaged web app.

    • This enables strong code sharing between WhatsApp Web and desktop apps.

So in short:

  • Native group (Android/iOS) = no cross-sharing

  • Web + Desktop group = heavy cross-sharing (wrapper strategy)

-----------------------------------

Section 2. "Web Wrapped" Windows Desktop App

Me: What is the most popular web + wrapper dev tool/stack for Windows OS now?

CG: When it comes to developing web-based desktop applications—especially for Windows—here’s a breakdown of the most popular and emerging frameworks used today:

1. Electron — The Established Leader

Electron remains the most widely-used framework for building desktop apps using web technologies.

Pros:

  • Developed by GitHub and backed by the OpenJS Foundation.

  • Large ecosystem with mature tooling, plugins, and documentation—trusted by major apps like VS Code, Slack, and GitHub Desktop. Wikipedia  Heart of Development

Cons:

2. Tauri — The Lightweight Challenger

Tauri is gaining popularity as a lighter, faster alternative to Electron.

Advantages:

Considerations:

3. Neutralino.js — Ultra Lightweight Alternative

Neutralino.js is another lightweight framework that uses the system webview and provides a JS-first interface.

Highlights:

Caveats:

  • Younger ecosystem, less mature tooling, and smaller community compared to both Electron and Tauri. Reddit

Real Conversations from Developers

From Reddit discussions:

“Electron is more popular—it has a larger community and plugins… if performance and smaller app size are critical, Tauri could be the way to go.” Reddit

And one enthusiastic user said:

“I switched to Tauri… a significantly reduced .dmg file size… Tauri is remarkably efficient.” Reddit

Summary Table

FrameworkPopularityApp SizePerformanceLanguage RequirementBest For
ElectronVery highLarge (~100+ MB)GoodJavaScript/Node.jsSpeedy dev + massive ecosystem
TauriGrowingTiny (~2–10 MB)High & efficientRust (backend) + JS/HTMLLightweight apps with tighter UX
NeutralinoNicheTinySimilar to TauriPure JS front & backendUltra-light apps, minimal tools

Verdict: What’s Most Popular for Windows?

Electron remains the dominant choice—trusted, reliable, and widely supported.

However, Tauri is emerging fast as the modern alternative for those who prioritize performance, security, and small bundle size.

If you're building a web-wrapped Windows app and value lightweight performance, Tauri is worth serious consideration.

...

[I moved to a new chat, gave some intro and asked whether Timestamp Tracker Windows app could be created using some web wrapper software for Windows.]

CG: Good question 👍 Let me break it down for you:

1. What is a "web wrapped" Windows app?

It simply means your web app (in your case, Expo Web build of Timestamp Tracker) is placed inside a native desktop shell so it can run as a standalone Windows program.

  • The shell is usually Chromium (via Electron) or WebView2 (via Microsoft Edge).

  • To the user, it looks like a Windows app (.exe) but internally, it’s just showing your web app.

2. Options for wrapping your Expo Web app into a Windows .exe

🔹 Electron (most popular)

  • Free, open-source, widely used (VS Code, Slack, WhatsApp Desktop are built with Electron).

  • You package your web app (dist/) into Electron and ship it as .exe.

  • Pros: Huge ecosystem, works offline, full desktop APIs.

  • Cons: Heavy (every app bundles Chromium).

🔹 Tauri (lightweight alternative)

  • Newer than Electron, very lightweight (~5–10MB apps vs 50–150MB in Electron).

  • Uses system’s native WebView (Edge WebView2 on Windows).

  • Pros: Small size, faster startup, good security.

  • Cons: Smaller ecosystem than Electron, but growing rapidly.

🔹 Progressive Web App (PWA) + Windows Store

  • If you enable PWA features (manifest + service worker), you can publish directly to Microsoft Store as a Windows app.

  • Users can also “install” it directly from Edge browser (Add to Desktop).

  • Pros: Easiest, no extra packaging needed.

  • Cons: Limited access to native APIs, requires online mode unless you implement caching.

3. Which is easiest for you?

Since you already have an Expo Web build:

✅ Quick & Free way → Package it with Tauri (smaller) or Electron (simpler tutorials).
✅ No coding, just publish → Turn your app into a PWA and push to Microsoft Store.

4. Recommendation for Timestamp Tracker

  • If you just want a standalone .exe for personal use or sharing with friends → use Tauri or Electron.

  • If you want broad distribution via Microsoft Store → set up your web app as a PWA and submit it.

-------------------------

Section 3. Performance Comparison between React Native Windows and Electron/Tauri/PWA

Me: app performance wise will PWA app be as good as Electron / Tauri app?

[Skipping CG response.]

Me: Hmm. So Electron will enable native Windows API access but it won't really speed up the app, as the app will still run in Chromium.

CG: Exactly 👍 you’ve nailed it.

  • Electron ≠ performance boost.
    It always runs your app in Chromium, same as opening your web app in Chrome. The only difference is that Chromium is bundled inside your .exe.

  • What Electron adds is:
    ✅ Access to Node.js APIs (filesystem, processes, notifications, tray, etc.)
    ✅ Ability to ship a standalone Windows app (no browser required)
    ✅ Cross-platform packaging (Windows, macOS, Linux)

  • What it does not add:
    ❌ Faster rendering (still Chromium-based)
    ❌ Smaller size (apps are typically 100MB+)
    ❌ Lower RAM usage (each Electron app is like running another Chrome instance)

For Timestamp Tracker, unless you plan to add Windows-native integrations (like writing logs to arbitrary folders, showing system tray icons, background running, etc.), Electron doesn’t give you extra performance — it just gives you packaging + APIs.

👉 So if your goal is only:

  • “I want my web app as a Windows app” → Tauri or PWA are better.

  • “I want my web app + deep native Windows features” → Electron is the choice.

...

Me: If I use React Native for Windows and create a Native Windows app for my Timestamp Tracker app then it will NOT be running in Chromium. Am I right? If so, it could have better performance, isn't it?

CG: Good thinking 👌 Let’s unpack this carefully.

🔹 React Native for Windows

  • React Native itself = JavaScript + React UI.

  • On Windows, React Native doesn’t use Chromium. Instead:

    • UI is rendered with native Windows controls (via XAML/WinUI).

    • Business logic runs on JavaScriptCore (or Chakra, depending on version).

  • So yes — not Chromium-based.

🔹 Performance Compared

  1. Electron/Tauri/PWA

    • Render in a browser engine (Chromium/WebView2).

    • Every button, view, and animation is drawn by the browser.

  2. React Native for Windows

    • UI is rendered by native Windows components.

    • It’s closer to a “real Windows app.”

    • No Chromium overhead (no HTML/CSS layout engine).

👉 This means React Native for Windows can have better performance, especially for:

  • UI rendering (native controls are usually more efficient than browser DOM).

  • Memory usage (no full Chromium instance).

🔹 BUT — trade-offs

  • Complexity:

    • You need to actually build & maintain a separate Windows version of your app.

    • Your existing React Native + Expo code will not 100% work out-of-the-box — you may need platform-specific tweaks.

  • Ecosystem maturity:

    • React Native for Windows is solid but not as battle-tested as React Native for iOS/Android.

    • Some Expo APIs may not be supported yet.

⚖️ Bottom line for Timestamp Tracker

  • Yes, you’re right: a React Native Windows app is not Chromium-based and can be lighter + more native-feeling.

  • But: for a simple timestamp logger like yours, performance difference will be negligible — the bottleneck isn’t rendering speed, it’s just storing/reading timestamps.

  • The main gain would be native look & smaller footprint, not raw speed.

...

Me: I am using my Timestamp Tracker app example as just a way to learn about the various possibities for having a one source code base, running as Native app on Android and iOS and Windows and also as a web app. If my app has a lot of UI interactions, then React for Windows may provide near to similar app written using C# and Windows API. Am I on right track?

CG: Yes 🙌 you are thinking in exactly the right direction. Let me map this out in layers so it’s crystal clear:

🔹 1. Your Goal

“One source code base → Native Android, iOS, Windows, plus Web.”

That’s the holy grail of cross-platform development. Different stacks achieve it with different compromises.

🔹 2. React Native for Windows vs Web Wrappers

  • React Native for Windows

    • UI = native Windows UI layer (WinUI/XAML).

    • Very close in performance/feel to a C# + WinUI app.

    • Code re-use with iOS/Android React Native is high (business logic, component structure).

    • But you’ll still hit some platform-specific gaps (not all mobile APIs map neatly to Windows).

  • Electron/Tauri/PWA

    • UI = Chromium/WebView.

    • Performance and “native feel” always one step behind.

    • Code reuse is perfect (same web build runs everywhere).

    • App weight and memory usage higher.

🔹 3. React Native’s Position

React Native sits in between:

  • On Android/iOS/Windows → UI uses native system controls, not a web engine.

  • On Web → Uses React DOM (with react-native-web).

So:

  • Heavy UI apps (lots of animations, lists, touch gestures) → React Native for Windows will feel much closer to a true C#/WinUI app than Electron/Tauri.

  • Light utility apps → Difference won’t matter; web wrapper is easier.

🔹 4. Trade-offs for the “One Source” Dream

  • React Native + react-native-web + React Native Windows can indeed get you one JS/TS codebase → Android, iOS, Web, Windows.

  • But:

    • Some UI code will diverge (mobile vs desktop layout paradigms differ).

    • Some APIs won’t exist everywhere (e.g., mobile sensors vs desktop filesystem).

    • So it’s more like 80–90% shared code, 10–20% platform-specific.

⚖️ Bottom Line

✅ You’re absolutely right:

  • If your app grows into something with lots of UI interaction,

  • React Native for Windows can deliver near-native performance, much closer to a C# WinUI app than Electron/Tauri ever will.

❌ But:

  • Pure “write once, run everywhere without touching platform differences” is unrealistic.

  • It’s more “write once, tweak a little per platform.”

...

Me: Some amount of platform specific code would be unavoidable in a real app, even a small app. But if most of the source code base is the same for Native Android/iOS/Windows and Web, I think that's an awesome feature. Do you know of any well known software/app that uses React native for Windows for its Native (or near-Native to be more precise) Windows app?

CG: You’re absolutely on the right track—React Native for Windows is indeed gaining traction, and several well-known apps and platforms are already leveraging it to deliver performant, native-like Windows experiences using largely shared codebases.

Real-World Examples of React Native for Windows

1. Microsoft First-Party Apps

Microsoft has gone big on React Native for Windows (and macOS), implementing it in several flagship desktop experiences:

  • Xbox app on Windows: Delivers smooth animations, video playback, and a modern UI—written in React Native for Desktop.

  • Microsoft Store on Xbox: Rebuilt using React Native to achieve performance that’s over twice as fast and safer compared to earlier versions.

  • Office suite interactions (Word, Excel, PowerPoint): Components like commenting experiences and dialogs across platforms (mobile and desktop) use React Native. microsoft.github.io  biz4solutions.com

2. Other Microsoft Tools

  • Microsoft Settings App for Windows 11: Built in React Native, balancing native UX with cross-platform code sharing.

  • Office, Outlook, Teams, Xbox Game Pass: Many of these experiences use React Native for shared, powerful UI across platforms. BiztechCS  reactnative.dev

3. Messenger Desktop by Meta

  • Messenger Desktop for Windows (and macOS) uses React Native to build a smooth, native-like messaging experience. biz4solutions.com

Community and Developer Insights

“Microsoft is probably the biggest user. They’ve invested significant resources into RN for desktop, and even many apps in Windows 11 are written in it.” — Reddit discussion Reddit

“It is used by Facebook to build the Messenger app for Windows and a growing number of other 3rd parties.” — Reddit insight from a React Native team member Reddit

Summary Table

OrganizationApp / FeaturePlatformNotes
MicrosoftXbox app, Microsoft Store, Settings appWindows (Desktop)React Native for Windows used for high-performance UI
MicrosoftOffice, Outlook, Teams componentsWindows / macOSShared experience across desktop + mobile
Meta (Facebook)Messenger DesktopWindows / macOSFast, native-like UI via React Native

Why This Matters

  • Native feel & performance: Apps like the Xbox Windows app achieve silky-smooth animations and responsive UX, rivaling traditional C# and WinUI apps.

  • Shared codebase: Teams, Office, and internal Microsoft apps benefit from common UI logic across platforms, boosting developer productivity.

  • Customer-grade apps: These are not prototypes—they are mission-critical experiences used by millions, demonstrating RN for Windows’ maturity and viability.

So yes, you're absolutely right—React Native for Windows is enabling near-native performance and look-and-feel for complex UI apps, all while supporting a highly shared codebase across mobile and desktop platforms.

...

Me: I saw 2 to 3 mins of this May 2024 video from Microsoft Developer: Supercharging your React Native app for Windows | OD502, https://www.youtube.com/watch?v=4sbAvwukSWM . I am very pleasantly astonished by what I heard so far. I plan to see the whole 23 min. video later on.

My background is that I have done a lot of Windows apps in 1990s and early 2000s. After that while I still was in touch with Windows app development till 2011, it was not in depth. Now after a break of many years I am back into development and in past 1 or 2 years, while focusing on web app development using MERN stack, I also did some VB .Net app development on Windows desktop. 

What I saw so far in the video indicates that I could write Android/Windows/web app in React Native with platform specific code where required (quite different from Windows .Net programming with VB/VC#). I am astouned by that possibility. I mean, I think I will be able to invoke Windows API calls through platform specific code in my REact Native app and so I can take care of performance issues that I face, for the Windows app. That's just awesome.

CG: I can completely understand your excitement 🙌 — what you’ve just described is exactly why Microsoft (and now others) have been investing so heavily in React Native for Windows.

Let me connect the dots with your background:

🔹 Your Past Context

  • 1990s–2000s: Windows development → Win32 API, VB6, VC++, then .NET (VB.NET, C#).

  • Those worlds gave you full Windows API control, but you were locked into the Windows ecosystem.

  • When you stepped into MERN stack + web apps, you got portability but lost the ability to hit native APIs directly.

🔹 What React Native for Windows Brings

It’s almost like Microsoft said: “What if we gave web/React developers the ability to build apps that feel like native C#/XAML apps — but without forcing them to leave their JavaScript comfort zone?”

  • Cross-platform core: Same React Native code can run Android, iOS, Web, and Windows.

  • Windows implementation: Under the hood, React Native for Windows uses WinUI 3/XAML for UI rendering.

  • Native access: You can write native modules (C++, C#, Rust, etc.) that expose Windows APIs to your JavaScript code.

    • Example: You can call into the Windows file system, registry, Bluetooth stack, device APIs, etc.

    • From JS, you just call NativeModules.YourWindowsAPI.doSomething().

  • Performance-sensitive code: Heavy-lifting bits can live in the native layer (C++/C#), while 80–90% of your UI/business logic stays in React Native.

This is why you’re feeling that “astounded” reaction — it really is combining the best of both worlds you’ve worked in:

  • The reach and agility of JavaScript/React

  • The power and performance of Windows APIs

🔹 How This Looks in Practice

Imagine you’re writing your Timestamp Tracker but growing it bigger:

  • Shared React Native code: UI, state management, API calls.

  • Platform-specific pieces:

    • Android/iOS → use Expo APIs for storage, notifications.

    • Windows → you add a small C# or C++ native module that calls into the Windows.Storage API for richer file management.

  • From JS, your call looks like:

import { NativeModules } from 'react-native';

NativeModules.TimestampFileLogger.save("2025-08-27 20:33");

And under the hood, TimestampFileLogger is your native C#/C++ module talking directly to Windows.

🔹 Why This Is “Awesome”

  • You no longer face the “Electron trap” (Chromium everywhere, always a web app in disguise).

  • You can ship true Windows apps that sit beside .NET apps, but are written mostly in React/JS.

  • You can target mobile + desktop + web with the same architecture and majority of shared code.

⚖️ Bottom Line

You’re spot on:
✅ React Native for Windows gives you the ability to build cross-platform apps with shared logic.
✅ And when Windows performance or API access is needed, you can drop down into the native layer — just like you did with Win32/.NET back in the day.
✅ It’s a very different world from VB.NET app dev — but the philosophy (“you can always reach down to Windows APIs when needed”) is still alive.

----------------------------------------

Section 4. Porting/Upgrading React Native and Expo for Web app to React Native for Windows (Desktop app)

Me: Well, right now, Native Windows app is not in my near-term goals. But having done a ton of VC++/C#/Win32/.Net stuff in 1990s and 2000s, I am truly fascinated by this possibility of REact native app for Windows (as Native Windows app). So I may toy with the idea of exploring how easy/difficult it is to convert my simple Timestamp Tracker app to now have a Native Windows app, besides the Native Android and web app, it already has. This may give me some idea of how such a possibiity may be there and effort involved for it, if in some future React Native app I do, I need a Native Windows app version too.

CG: That’s a great way to approach it 👌 — you don’t need to commit to Windows app development right away, but just toying with it using your simple Timestamp Tracker app could give you a very realistic sense of:

  1. How much of your existing React Native + Expo code “just works” on Windows.

  2. Where you hit platform-specific differences (e.g., storage, UI layout, APIs).

  3. What the developer workflow feels like (build, debug, deploy on Windows vs Android/web).

🔹 What you’d likely discover

  • UI & logic portability: Most of your React components, hooks, and state management code will run unchanged.

  • Expo gap: Windows is not a first-class Expo target yet, so some Expo APIs won’t just work. You may need to “eject” from Expo or use community packages.

  • Platform-specific APIs: For something simple like Timestamp Tracker (just recording times), Windows support might be almost trivial. But if you added things like notifications, file dialogs, or system tray icons, you’d explore writing/using Windows-specific native modules.

  • Tooling: You’d use Visual Studio (the full IDE, not VS Code) for the Windows project parts, alongside your Node/JS tooling. This will bring back some of the “old school” flavor from your VC++/.NET days.

🔹 Effort vs Learning Value

  • For Timestamp Tracker → Effort is low, because it’s so simple. The learning return is high, since you’ll see how React Native “bridges” to Windows without being overwhelmed by complexity.

  • For a real future app with more UI interactions → You’ll already know whether Windows support is practical and how much divergence from mobile/web code you should expect.

🔹 Suggested Exploration Path

If you decide to toy with this later:

  1. Keep your Expo Android + web versions as they are.

  2. Create a separate React Native Windows test branch (not Expo-managed).

  3. Port over the Timestamp Tracker components → see what runs, what breaks.

  4. Add one tiny Windows-only feature (e.g., save timestamps to a .txt file in Documents folder).

    • That’ll give you a taste of invoking Windows APIs via native modules.

⚖️ In other words:

  • For day-to-day work, stick to Android/web (your current focus).

  • For occasional exploration, play with RN for Windows using Timestamp Tracker.

  • For future bigger apps, you’ll know upfront if “write once, run everywhere (including Windows)” is viable for you.

======= end of ChatGPT chat extracts ====================================

Later I saw this whole video: Supercharging your React Native app for Windows | OD502, https://www.youtube.com/watch?v=4sbAvwukSWM by Microsoft Developer, 23 mins, May 2024. The video is good but comments on it indicate that some people have faced issues with React Native for Windows. The video walks the viewer through porting a simple React (Web) Note taking app to React Native for Windows as a first step. The next step is to add Windows Text to Speech feature to the  Windows (Desktop) app using Windows OS API. IFIRC, she shows it being done in two ways.

Get started build a desktop app with React Native for Desktop, https://learn.microsoft.com/en-us/windows/dev-environment/javascript/react-native-for-windows

Following article talks of Expo issues when porting to Windows. Looks like Expo is the big tripping up point as Expo does not seem to have support for Windows platform.
Building an Expo App for Windows: A React Native Developer’s DoomsDay, https://drebakare.medium.com/building-an-expo-app-for-windows-a-react-native-developers-doomsday-7c70ad732b41 , Mar. 2025

My current thinking is that given that Timestamp Tracker is a small app, I could invest some time in trying out the procedures given in above links to add support for/port to Windows, in a test project (as suggested by CG). But I should not spend too much time on it. If the port is successful and if time permits, I could consider adding Windows Text to Speech feature, say for the Note or for an entire timestamp entry using Windows OS API, as shown in above Microsoft Developer video.

React Native without Expo project could have better chances of easier port/upgrade to support Windows platform.

Comments

Post a Comment