CraysNostur
Nostur is a Nostr client built specifically for iPhone, iPad and Mac users. It is not trying to be the most generic cross-platform client. Its center of gravity is Apple-native software: local storage first, iCloud sync where it helps, relay publishing where it belongs, and enough Nostr protocol work to handle zaps, remote signing, DMs, live events, media and multi-account daily use.
An Apple-native Nostr client with a point of view
Nostur is one of the clearest Apple-first clients in the Nostr ecosystem. The official site presents it as a Nostr client for iPhone and macOS, while the App Store lists it as `Nostur - Nostr client` in Social Networking and Utilities. That platform focus matters. Nostur is not a generic web app with a mobile wrapper. It is a Swift application that leans into iPhone, iPad and Mac conventions, local storage, system notifications, media handling, Keychain storage and CloudKit sync.
The client is built by Fabian Lachman and published through `nostur.com`, with the public Nostr contact `npub1n0sturny6w9zn2wwexju3m6asu7zh7jnv2jt2kx6tlmfhs7thq0qnflahe` shown on the site and README. The repository `nostur-com/nostur-ios-public` is public, GPL-3.0 licensed and written in Swift. As of June 12, 2026, GitHub showed the repository as active, with a June 12 top commit named `Clean up`, 99 stars, 18 forks and 26 open issues. That makes Nostur unusually inspectable for an App Store client.
The best way to read Nostur is as a client with a strong product philosophy. It is social-media oriented, but it is also trying to reduce unnecessary dependence on relays for personal storage. It wants to publish to relays, read from relays and participate in Nostr's shared event network, while keeping the user's data local first. That choice shapes the entire app: accounts, sync, feeds, DMs, relays, NWC zaps and the limits of what a client can promise.
The mission is local first
Nostur's `MISSION.md` is worth reading before judging the app by screenshots. It says the goal is to enable freedom to communicate and argues that reach should depend on who wants to listen, not on a third-party algorithm. That sounds broad, but the practical part is more interesting: Nostur says your data should live on your device first, iCloud second and third-party relays third.
That is a distinctive position inside Nostr. Many clients treat relays as if they are the user's long-term storage layer. Nostur's mission warns that using relays as personal storage can recreate centralization pressure, just as email became concentrated around a few large providers. Nostur still publishes to relays and can use private relays, but the app's design assumes the device should have a durable local record rather than depending on a public relay to remember everything.
The Apple part is explicit too. The mission admits that building for Apple platforms is a limitation, especially around zaps and platform rules, but argues that if the target user already trusts Apple for messages, photos, calendars, reminders and device security, then using iCloud sync can be a pragmatic improvement over scattering personal state across random relays. A privacy purist may disagree. A normal Apple user may find the tradeoff easier to understand than managing relay storage manually.
A real App Store app, not just a repository
Nostur is distributed like a normal Apple app. The official site links to the App Store and to a direct Mac download. The App Store lookup record shows release date May 29, 2023, bundle ID `nostur.com.Nostur`, seller `Fabian Lachman`, a free price, a 17+ content rating and a current version release date of May 28, 2026 for version 1.28.0. The supported-device list spans iPhone, iPad and Mac desktop targets, and the App Store copy describes it as a social media client for the open Nostr network.
The direct Mac path matters because Nostur has users who want the same Nostr client across phone, tablet and desktop. The official homepage linked version 1.28.0 as a DMG download when checked, while GitHub's v1.28.0 release also carried a `Nostur-1.28.0.dmg` asset. A reader should prefer those official paths over random mirrors, especially because a Nostr client can hold keys, messages, account history and wallet connections.
App Store distribution also creates a tension that Nostur does not hide. Apple review and platform rules affect what an iOS app can do around payments, content and user-generated material. Nostur's mission mentions zap restrictions by Apple, and the release history shows steady work on payment UX, media, moderation and reports. Nostur is therefore not a pure protocol artifact. It is a Nostr client living inside the Apple ecosystem, with all the convenience and constraints that implies.
Version 1.28.0 shows the current shape
The 1.28.0 release is a useful snapshot of where Nostur stands. The GitHub release was published on May 25, 2026, and the App Store record lists the current version date as May 28, 2026. The release added private zaps, custom emojis, muted words, more relay connection statistics, a toggle to never connect to a relay, a relay information sheet on relay feeds, a black-background theme, Mac column refresh buttons, DM reactions, key export, video-posting refinements and more fiat-currency display choices.
The improvements tell the same story from another angle. The release notes mention avoiding too many concurrent relay requests, better rendering of deeply nested quotes, optimized DM file handling, improved DM relay detection and setup, better voice-message audio format detection, improved video thumbnail loading, better URL detection and easier expansion of posts. Those are not flashy launch features. They are the kind of fixes a client accumulates when real users live inside it.
The fixes are equally practical: relay feeds not loading, backtick rendering, animated GIF and WebP hangs, video crashes, private reaction issues, private reply thread issues and missing zap animation. That mix is a good sign for readers. Nostur is not a static listing entry. It is a fast-moving app that has enough daily-use surface to generate detailed fixes across relays, media, DMs, zaps, Mac columns and rendering.
The interface is broad by design
The feature list on `nostur.com` reads like a mature social client rather than a minimal Nostr proof of concept. It includes multiple account posting, guest account mode, media uploads, post previews, animated GIF picking, iPad and macOS panes, custom lists, local post storage and export, bookmarks, personal notes, follow and explore timelines, like undo, name autocomplete, Lightning zaps, wallet selection, DMs, NIP-05 verification, badges, block lists, silent follows, muted conversations and notification badges.
It also includes more specialized Nostr behaviors: relay configuration, restoring deleted contacts, deletion requests, user and post reporting, followable hashtags, undo send after posting, offline posting, relay feeds, music streams, login with nsecBunker and imposter detection. A lot of clients can post and read notes. Nostur is trying to be the Apple client where a user can manage the messy parts of Nostr without leaving the app every few minutes.
That breadth will not suit everyone. A narrow client can feel calmer, especially for a first Nostr session. Nostur is more ambitious: it wants to be a place where a daily user reads, posts, replies, zaps, checks live activity, manages relays, moves between accounts, handles media and keeps local history. The payoff is depth. The cost is that a new user should spend time learning settings before trusting every surface.
Storage, sync and the Apple stack
The repository documentation and source point to a local data layer built around Core Data with CloudKit sync. Internal project guidance names Core Data and CloudKit as the storage layer, while the source tree contains Core Data entities for accounts, events, contacts, notifications, NWC connections and DM state. The app is not merely streaming relay data into a temporary UI. It keeps a local model of the user's Nostr world.
Key handling uses Apple's Keychain through `KeychainAccess`, with account code reading, storing and removing private-key material under the Nostur service. That is the expected direction for an Apple-native app, but it still asks for trust. If a user imports an nsec, the device and app become part of that key's custody story. If a user connects through remote signing, the trust story moves toward the signer and session state.
The sync decision is the heart of Nostur's philosophy. Core Data and CloudKit can make contact lists, feeds, drafts, account state and app preferences feel reliable across Apple devices. They can also put some app state into the Apple account boundary. That may be a good tradeoff for the target audience, but it should be conscious. Readers who want a strictly relay-only or Apple-avoidant setup should understand that Nostur is intentionally not designed that way.
Accounts and remote signing
Nostur supports several account modes. The official feature list includes a guest account and nsecBunker login, and the code shows account import paths for private keys, bunker URLs and remote-signer accounts. The `AddExistingAccountSheet` checks for `bunker://` URIs and `nsecbunker` forms, asks for a relay when needed, creates or reuses a CloudAccount and connects through the remote signer manager. The accounts sheet labels remote-signer accounts visibly.
The NIP-46 implementation is substantial. `RemoteSignerManager` creates session keys, connects to the bunker relay, sends connect requests, asks for the public key, signs events through the remote signer and stores session secrets through `NIP46SecretManager`. The code includes fallback behavior when a signer cannot return `get_public_key`, and recent commits fixed a startup race around NIP-17 DMs. This is real protocol plumbing, not just a login-button label.
Readers should still test remote signing carefully. NIP-46 reduces the need to paste a primary nsec into the app, but it creates a session relationship between Nostur and the signer. Confirm which signer you use, how approvals are shown, which relay carries the remote-signing messages, how to revoke the session and what happens when the signer is offline. A remote signer is safer only when the user understands the consent and recovery path.
Relays are visible and configurable
Nostur gives relays more attention than a simple feed client. The feature list includes relay configuration and relay feeds, and version 1.28.0 added more relay connection statistics, a relay information sheet and a toggle to never connect to a specific relay. The code creates kind 10002 relay-list metadata for new accounts, tracks relay connection pools and provides relay-feed settings where a user can authenticate as a chosen account.
Relay Autopilot appears in the contact-feed settings, where feeds can use outbox behavior and additional relay choices. The source also distinguishes normal relay messages from NWC relay messages and Nostr Connect relay messages. That matters because one Nostr app may be talking to public relays for social content, dedicated relays for wallet operations and bunker relays for remote signing at the same time. A good client should not blur those paths.
The practical advice is to open the relay settings early. Check the defaults, inspect relay feeds, look at connection statistics and use the new `never connect` behavior when a relay is noisy, broken or unwanted. If a timeline is missing posts, the problem may be relay choice rather than Nostur's renderer. If zaps or remote signing fail, the relevant relay may not be the same relay that carries your home feed.
Zaps and Nostr Wallet Connect
Nostur has a mature zap surface. The feature list includes Lightning zaps and Lightning wallet selection, while the code contains NWC connection entities, NWC request and zap queues, NWC relay connection setup and Nostr event kinds for NWC info, request and response. The Nostr kind enum maps 13194, 23194 and 23195 to NWC info, request and response, matching the Nostr Wallet Connect pattern.
The app can create an Alby NWC connection or a custom NWC connection, store connection information, add an NWC relay connection to the connection pool and use NWC for instant zap flows. Zap buttons fall back to non-NWC behavior when NWC is unavailable, while profile, post and live-event zap surfaces can route through NWC when ready. Version 1.28.0 also added private zaps and behavior such as setting a zap private when zapping a private reply.
Nostur is still not a wallet in the narrow sense. It is a social client that can control a wallet through NWC and related Lightning flows. Keep that distinction sharp. A good setup uses a wallet with limits, a small test payment, visible approval behavior and an easy revocation path. If a zap fails, the likely cause can sit in the client, LNURL endpoint, NWC relay, wallet permission, wallet balance, recipient metadata or relay delivery.
Direct messages are moving to the modern stack
Nostur's DM code shows the transition from older encrypted direct messages to newer private-message patterns. The Nostr kind enum includes legacy direct messages, gift wraps and kind 10050 DM relay lists. The DM conversation code detects whether participants have DM relays, can create giftwrapped events, stores rumor events locally and sends wrapped events to recipient DM relays with fallback behavior.
The app also handles file messages, private replies, DM reactions and message requests. Version 1.28.0 mentioned optimized DM file handling, improved DM relay detection and setup, showing reactions on DMs, and fixes for private reactions and private reply threads. Those details are important because DMs are one of the hardest parts of Nostr UX: encryption, relay selection, local history, notifications, attachments and multi-device behavior all have to line up.
For sensitive conversations, test before relying. Send low-risk messages across devices, inspect whether message requests appear, check if notifications arrive, confirm how attachments behave and learn how DM relay lists are set. Nostur's direction is strong, but private messaging on Nostr is still a moving target. A client can implement the right protocols and still need careful user testing in the exact device and relay environment.
Media, video and Blossom-adjacent flows
Nostur is not text-only. The site lists media uploads, GIFs, image previews, GIF and video playback, music streams and video-posting refinements. The release notes for 1.28.0 mention stripping audio when posting divine video, including poster images, improved video preview thumbnail loading, animated GIF and WebP playback fixes, and a video crash fix. The app is clearly used for the media-heavy side of Nostr, not only short notes.
The source also includes authenticated media upload helpers. Account profile image helpers, App Intents and DM attachment paths call `getBlossomAuthHeader`, which indicates signer-authenticated upload flows rather than only anonymous URL pasting. The Swift package list includes media libraries such as Nuke for image loading, Gifu for GIF playback and LiveKit for realtime media sessions. That stack is what an Apple client needs when it wants Nostr media to feel normal.
Media should still be treated as distributed infrastructure. A Nostr event can reference a file, but the file itself lives on a server, Blossom host, streaming service, upload host or other storage path. Nostur can make posting and previewing smoother; it cannot guarantee that every third-party host keeps every file available forever. Before posting important media, check which service receives it and whether the resulting event contains enough metadata to be useful in other clients.
Live events, Nostr Nests and streams
Nostur has more live-media support than a typical timeline client. The 1.16.0 release added Nostr Nests integration and live video streams and chats. The current code includes LiveKit, `LiveKitVoiceSession`, `NRLiveEvent`, stream detail views, audio-only bars, live-event banners and handling for kind 30311 live events with streaming URLs, recordings, status, participants, relays and service tags. It can display HLS streams and LiveKit-based rooms.
The code around live events also intersects with authentication and payments. Comments in `NRLiveEvent` describe LiveKit rooms where clients authenticate to the service tag using NIP-98 HTTP auth to obtain an access token. Live stream participant views can show zap buttons and route zaps through NWC when available. That makes live events a good example of Nostr as coordination: the event is public metadata, while media, auth and payments may involve separate services.
For readers, the live surface is attractive but dependency-heavy. A live event may depend on relays carrying the event, a streaming provider, LiveKit or a compatible service, HLS playback, participants publishing correct tags and the app being able to authenticate when necessary. Nostur packages much of that into a native interface, but the moving pieces remain. Test it with public streams before depending on it for hosting or joining something important.
Moderation is local, visible and imperfect
Nostur includes many user-control tools: block lists, muted conversations, muted words, reporting, content settings, notification controls, followable hashtags, silent/private follows and imposter detection. Version 1.28.0 added a muted words list, while older releases added or refined relay stats, WoT spam filtering, Nostr Dunbar Number settings and profile safety labels. Those tools are not optional polish in Nostr; they are survival features.
The important thing to understand is where control happens. A Nostr client can hide posts, mute people, avoid relays, warn about imposters, stop loading certain media and publish reports. It cannot make every relay delete public events, prevent every client from showing an event or centralize moderation decisions for the whole network. Nostur's user controls shape what the reader sees and how the reader participates.
That makes Nostur a good fit for users who want client-side agency rather than platform-wide paternalism. It also means users must learn the controls. Open the mute and block settings, inspect relay behavior, learn what reporting does, and test how private follows or silent follows show up across clients. A strong Nostr client should make the user's local view manageable without pretending to be the ruler of the whole network.
What to test before making it your main client
Start with identity. Try guest mode or a test account first. Then test the account path you actually plan to use: imported nsec, encrypted key, nsecBunker/NIP-46 remote signer or another account mode. Confirm where keys live, how Keychain behaves, how account switching works, whether key export is available on your version and how you would remove an account from every Apple device involved.
Next test relays and sync. Open your following feed, explore feed, relay feeds, profile pages, hashtags, notifications and DMs. Compare important threads in another client so you can tell the difference between a missing relay, a stale local database and a UI issue. If you rely on iCloud sync, test the same account on two devices and watch what actually syncs. Nostur's local-first model is valuable only if you understand the local and cloud boundaries.
Finally test money, messages and media with low stakes. Connect an NWC wallet with spending limits, send a tiny zap, confirm the wallet history and check whether Nostur sees the receipt. Send non-sensitive DMs across devices and relays before treating the private-message stack as routine. Upload a small image or video and inspect the resulting event in another client. Nostur can become a very comfortable Apple home for Nostr, but it should earn that trust one surface at a time.
Who Nostur is best for
Nostur is strongest for people who already live on Apple devices and want a Nostr client that feels like native software. If you use iPhone, iPad and Mac together, the local database and CloudKit philosophy may feel more practical than a web app that forgets everything when a tab changes. The app's feature set is broad enough for daily social use, with enough protocol depth for users who care about relays, zaps, DMs and signers.
It is also strong for readers who want a client with a clear maintainer and visible source. Fabian Lachman's public repository, mission document, release notes and support path make Nostur easier to evaluate than a black-box social app. You can see the dependencies, the account code, the NWC code, the DM code, the relay code and the release history. That transparency does not remove risk, but it gives serious users something to inspect.
Nostur is less ideal if you want a platform-neutral client, a browser-only workflow, Android support or a client that avoids Apple services by design. It is not trying to be all things to all people. Its value is narrower and more useful: a deep Apple-native Nostr client that treats local state seriously, keeps relays in their proper role, embraces NWC and remote signing, and gives everyday users a real chance to live in Nostr without feeling like every action is a protocol exercise.
Sources worth opening
A useful reading path starts with the official Nostur site, the App Store record and the public GitHub repository, then follows the README, mission, credits, release notes, package dependencies and source files behind accounts, relays, zaps, NWC, remote signing, DMs, live events, storage and protocol support.
- Nostur official site
- Nostur App Store listing
- Apple iTunes lookup record for Nostur
- Nostur GitHub repository
- Nostur June 12, 2026 main-branch commit
- Nostur README
- Nostur mission
- Nostur credits
- Nostur GPL-3.0 license
- Nostur v1.28.0 release
- Nostur v1.27.0 release
- Nostur v1.16.0 release
- Nostur v1.15.0 release
- Nostur Swift package resolution
- Nostur account manager source
- Nostur existing-account import sheet
- Nostur account state source
- Nostur NIP-46 remote signer manager
- Nostur NIP-46 secret manager
- Nostur app state source
- Nostur Nostr kind source
- Nostur Nostr message helpers
- Nostur message parser
- Nostur NWC connection properties
- Nostur NWC zap queue
- Nostur NWC zap button
- Nostur profile zap button
- Nostur payment amount selector
- Nostur DM conversation view model
- Nostur DM conversation info sheet
- Nostur GiftWraps manager
- Nostur relay feed settings
- Nostur contact feed settings
- Nostur new account sheet
- Nostur data provider
- Nostur profile image helpers
- Nostur App Intent post source
- Nostur live event model
- Nostur LiveKit voice session
- Nostur stream detail view
- Nostur live event Nests API source
- Nostur NIP-05 verifier
- Nostr NIPs repository
- NIP-05 DNS-based identifiers
- NIP-17 private direct messages
- NIP-42 authentication of clients to relays
- NIP-44 versioned encryption
- NIP-46 Nostr remote signing
- NIP-47 Nostr Wallet Connect
- NIP-56 reporting
- NIP-57 Lightning zaps
- NIP-59 gift wrap
- NIP-65 relay list metadata
- NIP-98 HTTP auth
- NostrApps listing for Nostur
- LiveKit Swift SDK
- KeychainAccess
- Nostr Essentials dependency
