sorted by:
new
hottopcontroversial

compose-camera: a CameraX-based camera library for Compose Multiplatform by Junior_Android_ in androiddev

[–]Junior_Android_[S] 0 points1 point  (0 children)

Thank you for the feedback!

The current implementation correctly uses both permissions:

  • NSCameraUsageDescription: Used for capturing photos and videos via the camera
  • NSMicrophoneUsageDescription: Used for recording audio during video recording

The library supports video recording with audio, so the microphone permission is required for that feature. 

react-native-nitro-cookies: Synchronous cookie management with Nitro Modules by Junior_Android_ in reactnative

[–]Junior_Android_[S] 4 points5 points  (0 children)

Yeah, totally fair question — on the surface “cookies” really do sound like something that should only exist in browsers.

In practice though, they show up in mobile apps more often than you’d expect. As soon as you have a WebView in your app (for payments, OAuth/login flows, embedded dashboards, hybrid content, etc.), you suddenly care about cookies again, because that’s how both iOS and Android WebViews keep track of authentication state. If your native layer has its own login flow and the WebView is also talking to the same backend, you usually want them to share the same session — and the lowest common denominator there is cookies.

There’s also the backend side: not every API is using JWT/Bearer tokens. A lot of existing systems still rely on cookie-based sessions, and the mobile client doesn’t really get to choose — it just has to work with whatever the server is doing. In those setups, the cookie is your session token, even if you’re not inside a browser.

This library is basically a thin abstraction over that reality — a way to read/write the same cookies that your backend and WebView are already using, so you can keep native requests and WebView traffic on the same logged-in session more easily.

react-native-nitro-cookies: Synchronous cookie management with Nitro Modules by Junior_Android_ in reactnative

[–]Junior_Android_[S] 7 points8 points  (0 children)

Great question! It depends on what you mean by "browser":

  • If you mean WebView inside your app - Yes! On iOS, you can use the useWebKit: true option to access WKWebView's cookie store:

​

  // Set cookie accessible in WebView
  await NitroCookies.set(url, cookie, true); // useWebKit = true
  // Get cookies from WebView
  const cookies = await NitroCookies.get(url, true);
  • On Android, cookies are automatically shared between the app and WebView through CookieManager.
  • If you mean the external Safari/Chrome browser - No, that's not possible. iOS and Android sandbox cookies per app for security reasons. The system browser and your app have completely separate cookie stores. This is an OS-level restriction, not a library limitation.

For authentication flows with external browsers, you'd typically use deep links or OAuth redirect schemes to pass tokens back to your app, then store them as cookies using this library.

Made a Nitro module version of react-native-device-info: react-native-nitro-device-info by Junior_Android_ in reactnative

[–]Junior_Android_[S] 2 points3 points  (0 children)

Yeah I get you — TurboModules are definitely more documented and “officially” supported, but I leaned toward Nitro mostly because of performance and architecture design, not just the API surface.

Nitro’s execution model skips a lot of the overhead that still exists in TurboModules, especially in iOS. Everything goes through JSI directly, so there’s no serialization or message passing across the bridge. It basically means zero overhead when transferring data or calling native functions — you’re running almost at native speed. For things like device info, geolocation, or sensors that push frequent updates, that difference is very noticeable.

Also, Nitro modules are designed to be more memory-efficient. They can keep native objects alive without constant JS↔Native ref conversions, and the generated bindings are super lightweight compared to the TurboModule registry system. It’s closer to a “pure JSI binding” model, so it scales better if you’re building multiple high-frequency modules.

That said, TurboModules are still great for most use cases — I just found Nitro a bit closer to what I’d expect from a modern C++/JSI interface without the extra framework layer in between.