Add LangSearch web search and iOS JavaScriptCore support

[tkatsampanis]

Changes

• Expose the existing web-search functionality through the Settings UI
• Add LangSearch as a web-search provider
• Add LangSearch web-search configuration
• Disable Hermes for the iOS build
• Configure JavaScriptCore for iOS
• Update the React Native Pod configuration accordingly
• Configure automatic Apple Development signing
• Use a separate development bundle identifier for the iOS development build

Summary

The web-search functionality was already present in the project, but the available web tools and configuration were not exposed through the app's Settings UI. I added the necessary Settings entry and configuration so that users can actually access and configure web search from within the application.

For the web-search provider, I added LangSearch. I chose LangSearch because many other web-search APIs require a paid subscription or paid API usage, while LangSearch currently provides a free Web Search API for individuals and small teams. It uses a standard API key with Bearer authentication, making it straightforward to integrate without introducing a paid search service for users.

LangSearch's official repository describes its Web Search API as a free API and provides the Bearer-authenticated endpoint used by the integration:
https://github.com/langsearch-ai/langsearch

The goal was therefore to make web search actually accessible from the app while using a search API that users can access for free rather than requiring a paid search provider.

iOS / Hermes changes

I also disabled Hermes for the iOS build and configured the project to use JavaScriptCore instead.

The reason for this change was a build/runtime issue I encountered while trying to get the project into a working iOS development configuration. With Hermes enabled, the iOS build setup was causing problems in my environment, preventing me from getting a successful development build onto the device.

I therefore switched the iOS configuration to JavaScriptCore and updated the React Native Pod configuration accordingly. This allowed me to get the project into a buildable development configuration on my machine.

I also changed the iOS development signing configuration to use automatic Apple Development signing and a separate development bundle identifier, so that the development build is isolated from the production App Store application.

Physical-device testing limitation

I was able to build and configure the iOS project locally, but I could not complete a physical-device run on my target iPhone.

My development machine is a 2021 MacBook Pro with an M1 chip, running macOS Sonoma 14.7.4 and Xcode 16.2.

The target device was an iPhone 17 Pro Max running iOS 26.6.1.

The iPhone is detected correctly by macOS and Apple's command-line development tools, but Xcode 16.2 does not contain the required DeviceSupport files for iOS 26.6.1. As a result, Xcode cannot mount/support that device for deployment.

I could upgrade the macOS/Xcode environment, but I currently do not have another Mac available for testing, so I cannot honestly claim that I completed a physical-device test on the target iPhone.

I would therefore appreciate your review and, if possible, testing of the iOS changes on a development environment with a compatible Xcode/iOS device-support combination.

If you consider these changes useful and stable, I would be happy for them to be incorporated into the project and potentially considered for a future App Store release.

[a-ghorbani]

Thanks for the work here. I can't take this as it stands. The branch carries your fork's whole identity and build environment alongside the feature, so most of the diff isn't reviewable as a change to this repo: eg rebrands in app.json, strings.xml, MainActivity.kt, etc. and local build settings (.devcontainer/) ...

The bigger issue: main already has the web-search subsystem under src/services/search/providers/, keychain-backed keys via SearchProviderStore, result budgeting, the read-URL allowlist, and a shipped Settings → Internet Search screen. Your branch point predates all of it, so this PR would replace that with a parallel implementation that skips the safety layers (notably wrapUntrusted()).

It also adds local-document search and a KV-cache feature that the description doesn't mention, with no tests and hardcoded English strings in Settings.

What I'd like to keep is LangSearch as a provider — a free-tier option is a genuine gap. Off current main that's a small change:

1. src/services/search/providers/langsearch.ts, same shape as providers/tavily.ts (contract in ../types.ts)
2. Wire into createSearchProvider in src/services/search/index.ts + an entry in src/store/SearchProviderStore.ts
3. A test alongside the existing provider tests

Would you close this and open that as a focused PR?

If you want to pursue the KV-cache or local-documents work, please open an issue for each first so we can agree on the design before you spend more time on code. Thanks.