Feature Requests

Hello, i am team lead and i would like that EAS updates can be done by my team but only for specific channel or project. Today, if i give "developers" status to the team members, they can do eas update for everywhere even production when we have CI/CD for this. Permission is handle by organization. If it will be by project, it will be already so nice but by channel will be even nicer. Thanks for your help !

I'm working on an app that stores a sensitive keypair. I'd love to recommend that users turn on strong biometrics if their device supports it. canUseBiometricAuthentication() in SecureStore only tells you that a device has strong biometrics currently enrolled . hasHardwareAsync() in LocalAuthentication tells you if a device is capable of weak biometrics, but not strong. It would probably be low-lift to place a param in hasHardwareAsync() here to specify strong biometrics. Otherwise, placing a new function in SecureStore would also work to check for device capability, not current enrollment. This would dramatically improve our app's UX.

Currently, when using DOM-based components (with "use dom" directive) in an Expo project, the Origin header is automatically set based on the execution environment. This can cause CORS issues when interacting with APIs that require a consistent Origin value. We propose adding support for a configurable baseUrl option in DOM components, allowing developers to explicitly define the base URL for requests. This would enable consistent Origin headers, improving compatibility with APIs that enforce strict CORS policies. Use Case • Developers using Expo WebView or fetch to communicate with backend APIs that require a fixed Origin. • Handling authentication flows where a specific Origin is expected. • Ensuring uniform behavior between development and production environments. Proposed Solution Introduce a baseUrl configuration option for relevant DOM-based components, allowing developers to override the default Origin header. This setting would be respected when making requests via fetch, WebView, or other applicable components.

Currently Expo uses https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession/init(url:callbackurlscheme:completionhandler:) internally when calling openAuthSessionAsync. This signature is deprecated and only supports custom scheme callback URLs. https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession/init(url:callback:completionhandler:) instead supports both custom schemes and universal links. It's only available from iOS 17.4, but it could be used conditionally.

I am porting a Three.js application to React Native, and I am using expo's GLView for WebGL support. While GLView supports most of my use cases, it is missing support for the compressedTexImage2D and compressedTexSubImage2D WebGL functions, which are required for loading compressed textures. See: https://github.com/expo/expo/blob/10c6a97d115d3f3bcca901f72bd7560d3ccfa0f7/packages/expo-gl/common/EXWebGLMethods.cpp#L600-L602 . It should be possible to support the following WebGL function signatures when WebGL2 is supported: compressedTexImage2D(target, level, internalformat, width, height, border, srcData) compressedTexSubImage2D(target, level, xoffset, yoffset, width, height, format, srcData) These are the function signatures used in the Three.js compressed texture class, though it may be possible to add support for the other function signatures. reference: https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/compressedTexImage2D https://github.com/search?q=repo%3Amrdoob%2Fthree.js%20compressedTexImage2D&type=code I have a branch adding support for the WEBGL_compressed_texture_etc for the above function signatures, and I would be happy to open a PR to expo if you want to accept this feature. You can view the branch here: https://github.com/expo/expo/compare/main...hmallen99:expo-gl/add-compressed-texture-support?expand=1 . Supporting WEBGL_compressed_texture_astc and WEBGL_compressed_texture_pvrtc would not be too much more work, and I believe it could piggyback off my branch.

supportedAuthenticationTypesAsync returns an array of types including FINGERPRINT, FACE, IRIS. However, hasHardwareAsync and isEnrolledAsync does not take an argument to look for a specific type. So for a Galaxy S10 you can have only FINGERPRINT ([1]) respond from supportedAuthenticationTypesAsync... but have have an enrolled FACE and not have an enrolled FINGERPRINT leading to buggy behavior. (see https://github.com/expo/expo/issues/7838#issuecomment-615486946 as to why this might happen) We could solve this by allowing hasHardwareAsync and isEnrolledAsync to take an argument that is the response from supportedAuthenticationTypesAsync

Please, add something like LocalAuthentication.hasBiometricChangedAsync. That should return true if fingerprints or face changed.

We need this feature for both of the platforms. This is an essential feature. Expo must add this to its' built-in modules: https://github.com/alinz/react-native-share-extension [1] https://developer.android.com/training/sharing/send [2] https://developer.apple.com/library/archive/documentation/General/Conceptual/ExtensibilityPG/Share.html#//apple_ref/doc/uid/TP40014214-CH12-SW1