Nora: an SNS browser that wraps Facebook, Instagram, Reddit, Threads and X in one ad-free app

The problem Nora targets: ten social apps, ten tracking surfaces

Most people who use several social networks end up installing several native apps. Each one brings its own notification channel, its own background sync, its own ad SDK and its own cookie jar. Nora takes the opposite route: it is a browser whose default purpose is social network sites. The README lists Bluesky, Facebook, Instagram, LinkedIn, Reddit, Threads, TikTok, Tumblr, VK and X (Twitter) as supported services, and describes the app as an "Android, iOS and Desktop browser optimized for social network services".

The audience is narrow and fairly clear. It is for someone who wants the web version of these sites, in one place, without ads, and who is willing to accept a webview rather than a native client. The README also names a companion project, Nora-Desktop, which "features a deck view to easily browse multiple timelines" and ships Linux, macOS and Windows builds. That deck view is the feature that most distinguishes the desktop variant from the mobile app; the mobile README does not describe an equivalent layout.

How the webview wrapper and injected scripts fit together

The README is short on architecture, but two lines give the mechanism: "Wrap the SNS websites in Android webview" and "Inject code to block ads". The repository layout supports that description. There is a content/ directory, and package.json defines a bundle script that compiles content/main.ts, content/webrtc.ts and content/youtube.ts into assets/scripts with a .bjs extension. Those injected scripts are the part that runs inside the page context, which is where ad blocking and the tracking-parameter removal happen.

The feature list describes what those injections do at the user level: EasyList and EasyPrivacy blocklists, removal of tracking URL query parameters, image download, video download for Facebook, Instagram, TikTok and X, text selection, zoom, and CSS customization. The app itself is an Expo and React Native project (main is expo-router/entry, and the scripts include expo run:android and expo run:ios), with a workspace entry for desktop. So the shape is: a React Native shell hosts a webview, and a separately bundled TypeScript payload is injected into every page.

Multiple accounts with separate cookie storage is the second structural decision. It matters because sharing one cookie jar across accounts is exactly how a web wrapper becomes unusable for anyone who runs a personal and a work profile. The README states the feature; it does not explain the storage mechanism.

Installing Nora and a first real use

For most users there is nothing to build. The README says to install from the App Store, Google Play or F-Droid, or to download the APK from GitHub releases. The store links in the README are the iOS listing id6758549275, the Play package jp.nonbili.nora, and the F-Droid package jp.nonbili.nora. The APK route points at the latest release page.

If you want to build from source, the README's Development section gives this sequence. It uses bun, and it links the workspace before installing:

bun link
bun install
bun dev
bun run android

bun dev runs the bundle script in watch mode, which rebuilds the injected scripts into assets/scripts. bun run android runs expo run:android --variant fullDebug, so the first Android build is a debug variant. The README does not give an equivalent command for a release build, and it does not document iOS build steps beyond the presence of an ios script in package.json.

After install, the first real use is to open one of the supported sites inside the app and sign in. Because accounts have separate cookie storage, the practical first step is to decide whether you want one profile or two before you log in anywhere, so you are not moving sessions later. The README does not document an account migration path.

Where Nora is the wrong tool

Nora is a browser, and the README does not claim otherwise. Anything that depends on a first-party native client is out of scope: the README lists no offline feed cache, no native share extension, and no push notification pipeline tied to the social networks themselves. If your workflow depends on background sync or on notifications arriving without the app open, a webview wrapper is the wrong architecture, and the README does not present it as a solution to that.

Ad blocking is the other boundary. The README names EasyList and EasyPrivacy as the blocklists, which means coverage tracks those lists. Sites that serve ads from the same origin as their content, or that change their markup, are not covered by a list-based approach. The README does not describe a fallback for that case, and it does not document a per-site exception mechanism.

The desktop story is split across two repositories. If you want the deck view, you are pointed at Nora-Desktop, not at this repository. Someone who installs the mobile app expecting the deck layout will not find it in this README.

How Nora differs from a native client and from a general browser

The nearest alternative is the official app for each network. The difference is architectural rather than cosmetic: a native client talks to the service's private API and renders its own UI, while Nora loads the website and modifies it from the inside. That gives Nora the blocklist, the URL-parameter cleanup and the CSS customization, and it costs Nora the things a native client gets for free, such as platform-level notification integration and rendering tuned to the device.

The other alternative is a general-purpose browser with an ad blocker extension. That gets you the same web pages and often better browsing, but not the per-account cookie separation the README describes, and not the download helpers for Facebook, Instagram, TikTok and X video. Nora's value is concentrated in those two areas: session isolation per account, and injected site-specific helpers. If you only need one account and a good blocker, a general browser is simpler. If you run several accounts across several networks, the isolation is the reason to pick Nora.

Maintenance, releases and the AGPL-3.0 licence

The repository is not archived, and the last push was on 2026-08-29. Releases in the weeks before that date were v0.8.9 on 2026-08-29, v0.8.8 on 2026-08-23 and v0.8.7 on 2026-08-18, so the project was shipping on a roughly weekly cadence through late August 2026. package.json carries version 0.8.10, versionCode 94 and buildNumber 35, which is ahead of the newest listed release tag.

Upgrade cost is mostly on the user side. Mobile installs through the App Store, Google Play and F-Droid update through those stores; APK installs update by downloading a new release. Self-builders pay a heavier price, because the injected scripts are bundled separately from the app shell, so a change in the blocklist or the site helpers means rebuilding assets/scripts as well as the app. The README does not describe a migration process for stored cookies or accounts between versions.

The licence is AGPL-3.0. That is a copyleft licence with a network-use clause: if you run a modified version as a service, the source obligations extend to users interacting with it over a network. For someone installing the app for personal use this changes nothing. For someone forking it and publishing a build, the licence terms govern what you must release. This is a description of the licence, not legal advice; read the LICENSE file in the repository before distributing anything.

Editorial conclusion

Nora suits people who want one app for several social networks, no ads, and separate cookie storage per account, on Android, iOS or desktop. It is the wrong tool if you expect native-app performance, offline feeds, or push notifications through first-party app code. Before adopting it, check the release page for the current APK, confirm your platform is covered by the mobile or desktop build, and read the AGPL-3.0 licence text if you plan to distribute a modified version.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes