xxG-2025-02: IOS app for haven

yom · October 10, 2025, 11:13am

Grant Proposal: IOS app for haven.

Overview

Hi, I am Om, I have discovered xxnetwork and haven thorugh MF.
My current go to chat app is Telegram and always wanted to replace with haven, but lack of support on phone is making that transition hard.
I have some friends who love keeping privacy and would be interested in haven app in their phone.

I asked in xxnetwork channel of haven chat about IOS plans and Rick said I can contribute and shared this link xxdk-examples/iOS at master · xxfoundation/xxdk-examples · GitHub
Since then I started experiementing on it and got some good results (see attached screenshots).

Now I am requesting for some funds/grants to support this development and feedback from community.

Grant Request

I am requesting 30,000 USD (25,50,000 XX Tokens)
Here is my proposal with milestones.

Milestone 1 — Auth and basic messaging (40%)

Features to implement

New Cmix using user provided secret
Codename selection at start
Codename import/export
Send and receive messages in channels
Send and receive direct messages (DMs)
Display reactions on messages
Basic channel list and DM list

Technical info

Identity and auth

Store password via Keychain Services: Keychain services | Apple Developer Documentation
Persist selected codename
Decodable: IdentityJSON

Data and models (SwiftData)

SwiftData: SwiftData | Apple Developer Documentation
@Model: User, Chat, ChatMessage, MessageReaction, Sender (https://developer.apple.com/documentation/swiftdata/model)
Integrate queries in views with @Query: Query | Apple Developer Documentation
Indices/keys aligned to Haven web IndexedDB where known

Remote Key-Value

Implement minimal remote key-value functions for channel manager’s “storage tag” (get, set, list, delete) with per-chat namespacing

Parsing and serialization

Decodable models for inbound payloads (ChannelJSON, ChannelSendReportJSON, IdentityJSON)
Decodable: Decodable | Apple Developer Documentation
JSONDecoder configured for server formats: JSONDecoder | Apple Developer Documentation
HTML to attributed text for message body via AttributedString(HTML: …); sanitize inputs

Messaging pipeline

EventModelBuilder protocol to convert events to SwiftData models
Use existing DMReceiver for DM events
Basic message send/receive wiring for channels and DMs

UI scaffolding

SwiftUI List: List | Apple Developer Documentation
ScrollView chat views: ScrollView | Apple Developer Documentation
NavigationStack: NavigationStack | Apple Developer Documentation
NavigationSplitView for side-by-side view on large screens (Mac, iPad): NavigationSplitView | Apple Developer Documentation
Message cell: sender, body; reactions rendered inline/summary
Enable text selection for messages: TextSelection | Apple Developer Documentation
Unread badges on lists (basic)

Milestone 2 — Channels and interactions (30%)

Features to implement

Join channel via invite/link
Leave channel
Toggle DMs (enable/disable DMs in app settings or switch to DM mode)
Open or start a direct message thread with a user if available
Reply to messages (threading and navigation to parent)
React to messages (add/remove user reactions)
Create channel

Technical info

Invites and channel management

Link parsing (DecodePublicURL) and join flow for channel links
Join DMs via invite links using modal sheet: https://developer.apple.com/documentation/swiftui/view/sheet(ispresented:ondismiss:content:)
Channel creation and leave operations reflected in local models

Reactions

MessageReaction entity persistence and aggregation per message
Update handling for add/remove and counts

Replies

Threading fields on ChatMessage (replyTo/thread metadata)
Navigation to parent and highlight behavior

DMs

Chat creation/open from user or message context
Availability checks based on toggle

Settings

DM on/off toggle persisted; gated UI/actions

Routing and error states

Join/leave/create feedback and failure handling in UI

Milestone 3 — UI/UX polish (20%)

Features to implement

UI polish and layout refinements
Show timestamps in conversation views
Group sender by color (consistent color per sender)
Swipe to reply gesture in message list
Context menus for message actions (copy, react, reply)
Show detailed xxdk load status on startup

Technical info

Rendering and formatting

Date formatting and localization for timestamps
Deterministic color assignment per sender

Gestures and interactions

Swipe actions mapped to reply
Context menus for actions: https://developer.apple.com/documentation/swiftui/view/contextmenu(menuitems:)
Copy text programmatically via UIPasteboard: UIPasteboard | Apple Developer Documentation

Status and diagnostics

xxdk load status surface: phases, progress, error states in a startup sheet/view

Milestone 4 — Release (10%)

Release

Publish to AltStore
Optional: Prepare and publish to App Store (may require additional changes)

Please share your feedback

More about me

I have worked before on haven secure browser extension with MF which is in review/audit phase. xxB-2024-003: Haven Browser Extension Implementation
Here is my website - https://ommore.xyz

Attachments

Screenshots of my experiment

rothbardian · October 12, 2025, 6:47pm

Great work.
What amount of failed/stuck sends do you see %-wise?

Too bad we relied heavily on Discord and I think after a hacking wipe-out all the great feedback that we had on xx Messenger iOS while it was new and users submitted feedback, was lost. It seems they nuked (or hid, in best case) all the xx Messenger feedback I posted here. #winning

Among things that I’d like are negative features, such as “disable URL preview” (even “textualize” would be great, to prevent accidental clicks). Since those may be easier to implement than “positive” features, you can consider them if you think they’d improve privacy.
Dummy/cover traffic was a great feature years ago and with latest phones (better battery life) it’d be still valuable to have if it’s not too much trouble.

In xx Messenger, exporting (backup) of IdentityJSON kind of sucked, as I recall it used SFTP (bizarre!) instead of S3 or something that has PQC. Unless we want to “share with Signal”, some backup or sharing method would be needed to prevent ID wipe-out that many xx Messenger users suffered.

yom · October 13, 2025, 2:04pm

For sends

10% fails, but I believe that can improved with some error handling and retrying from swift side.

Disable URL preview

For now I don’t have any url preview feature for iOS app, so it’s not issue for now.
If there is need for url preview feature,
I will add the option for disabling this and will set it on by default or ask user to confirm this while onboarding.

For accidental clicks on url, I can add confirm box, warning saying that privacy cannot be guaranteed for visiting website.

Exporting Codename

I don’t have much knowledge of xx Messenger, but for the app I am making,
I can make export import haven style, where it exports the codename to filesystem and allows importing from same.

I am trying to test xx Messenger but it seems to be blocked in my country(maybe pulled down from app store).

rothbardian · October 13, 2025, 2:20pm

Thank you for responding!

URL preview: I find the idea awful, but you’d be surprised how many people want strong privacy and aren’t willing to sacrifice any convenience. Some would even highlight outrageously brain-dead use cases such as animated GIFs (which, as we all know, are one of the worst kinds of preview material as far as privacy goes). Hey - even Signal does it, so who are we to object?

Yeah, no worries - it’s been a while… And yes it was pulled, I think the thing was “update your app to latest or else” and the choice was “else” because the app needed an overhaul, not an update.

https://learn.xx.network/cmixx/e2e-xxm - some background

GitHub - xxfoundation/elixxir-xx-messenger-iOS: This repo is a mirror of https://git.xx.network/elixxir/client-ios. - who knows if it can be built any more… And it used the old API, I don’t know if that API is still available.

About Cover Traffic - I think it wasn’t implemented (certainly no option was exposed to the user or admin) in Haven, but it was an option in xx Messenger iOS (and Android) (default: off, due to battery impact).

https://learn.xx.network/cmixx/coverTraffic

rick · October 13, 2025, 3:32pm

This is normal (you just can’t reliably contact a gateway sometimes and get a message in before the round starts ). Basic error handling will fix it. Haven does this handling I believe (perhaps it happens in the javascript library, I don’t recall).

yom · October 21, 2025, 9:10am

Small update

Improved UI

codename matched colors
better home ui

Added codename selector and password input backed by iOS secure keychain.

Screen record - Proton Drive

warnings · October 22, 2025, 7:38am

Just one question why you not develop that for Android, Linux, Windows and all other systems before do that on an unsecure system like iOS ?

Apple have the whole control over your phone and without error you can’t take the whole control by cutting all Apple servers communications. So they can scan your messages/images on both side. You can mix/hash/shred do what you want all will be on both end directly to the Apple servers.

If you want to do that for security purpose develop on operating system who let people secure them and cut all links with the manufacturer. At the end if people still haven’t understand what do Apple let people on Apple communicate with other systems.
Security have only one single rule, should have the whole control over every parameters and connections.

rothbardian · October 22, 2025, 9:41am

Here we go, valuable xx community feedback!
@warnings why don’t you start a campaign on the xx Discord to mobilize the community to vote against funding this dApp unless your demands are met?
#winning

yom · October 22, 2025, 10:05am

IIRC I think rick said in haven general chat that android is in progress,
I don’t have much experience linux and windows coding and I don’t like cross platform tools like electron since I believe they have performance overhead.
Also for desktops we can always use haven web app or install it as PWA/shortcut.
I personally use apple devices and I would benefit from such app.
Also I was going to do this for free in future, but with grant support I can put time into this now.

warnings · October 24, 2025, 8:31am

Ok missed that from Rick thank you for this information
I think it can add a great value to have apps compatible with many operating system and be able to store many things in a dedicated and secured container instead of a browser it will increase most probably the usage. Why not try a language cross platform or mostly as possible to not doing the same job multiple time ?
Why you still use Apple device for any “security” purpose after so many issues reported over years and continue using device/operating system than you can’t control at all ? I have never understand sorry. Security is full control over the device and software. Windows was good and become worst and worst over time most probably due to Apple who show a wrong way. Android is still open and Linux too.
Even Apple is closed as never seen before this company exist. They should support some cross platform code with good performance and reliable no ?

@ clueless

The idea isn’t bad just very sad to use probably the worst devices/software for security purpose to promote a secure network compatible only with one single platform. People who search this type of secure network want a secure operating system and whole control over the device that’s the base of security. Golden jail is my latest choice and will do all what I can before take this latest choice.

rothbardian · October 24, 2025, 9:19am

This isn’t a discussion about Coke vs Pepsi, our preferences or how the world is supposed to work.

iOS is a top mobile OS. Is it justified to create a grant proposal for it? It is.
The only question we are expected to answer is: do we have constructive feedback on the details of the proposal?

warnings · October 25, 2025, 7:27am

IOS is the worst OS about security so you can’t found worst. No control at all from the user side, a company decide for yourself what is good or not for you. They scan your private pictures for protect “children” of course. They are even be able to detect what piece of software run on your device without even touch your device physically. Instead of uninstall and do directly something on your phone they just send you a message to tell you than something wrong run on your device (no one other company do that on this world)
They have lost against Epic and should offer alternative to their fully controlled store. When release a new model they remove app who providing this feature to be able to sell this feature on their new device
Remove almost every external connectors/ports to be able to sell their proprietary products most of the time. It’s justice who should stop them and force USB standard connector by example. That’s just amazing they have keep one single user over time doing all of that.
They should now open an alternative store or way to install app to everyone if not win another trial after that. So even justice confirm what I write since many years.

This proposal use the worst OS ever about security. So first use OS providing full security when you want to promote a security related app and why not this OS but at the end may be even with a little warning than your text can be intercepted/stored/used/transmitted to US government by Apple like that no body will write anything confidential to these users because both end should be perfectly secured to secure a confidential chat. Microsoft should be checked on software side if record your screen or anything who be able to compromise security of the messages. Linux should be perfectly fine because these tools not exist with my actual knowledge everything is decentralized with possibility to own your own local repository of software. No one decide, check or control what you do on your Linux device.
So the idea is pretty good just have choose the wrong OS and the code should be cross platform for not doing multiple time the same job. You should never use storage provided by the manufacturer or OS (security = no trust) but your own based open source solution like Truecrypt or Veracrypt everything is open source and audited who give you 100% trusted storage location. You should type a password before each usage to unlock container. If app is closed container too so unavailable without your own password so only you will be able to read that.

If everything is done according to security so not have any trust to anyone. The usage will be worldwide if we respect every aspect of perfect security with an external audit of the code. A little warning when you reach any devices using OS who not respect security of the users at both end like iOS until Apple will be forced to respect users by worldwide justice. One day you will be able to use an offline Apple device without any link to Apple server but it will take many years or this company will disappear before when all users will have enough knowledge to understand by herself what they use. Android with Google services isn’t probably better may be a little like the OS is still open and can be rooted so the control can be taken over yet with a rooted firewall who can block everything to and from Google servers.

EDIT : Security is like hygiene: either you take care of it or you don’t.

rick · December 6, 2025, 7:47pm

I submitted a grant bounty for 3Mxx, which will go to this curator account:

6YvZ6LUwNN1N6nz2a645zDeXs3XQnFGQLgVRN1J6jqxsT7Lg

rothbardian · December 7, 2025, 4:49am

Good.

Loosely related, for the Android whiners: Getting Started with the Swift SDK for Android | Swift.org

yom · March 18, 2026, 11:54am

App Update

Hope all are doing well. It’s been a long time and sorry for the delay. I have been working on this app and have some updates. I am near completion of the first 3 milestones. I will start with the changes.

Change 1: UIKit for Chat Messages

UIKit is used for the chat messages list. Before, I planned to use SwiftUI with LazyVStack, but found out during testing that it is unstable for a chat UI.

Scroll glitches when loading new messages.
Unoptimized - every load calculates its message bubble sizes while rendering.
When loading old messages, the scroll position changes and jumps abruptly.

To fix this, I decided to switch to UIKit components, like UICollectionView with a custom UICollectionViewLayout. This allows for more control over scroll behavior and view caching like CGRect sizes. This change resulted in smooth scrolling even while old messages are syncing.

Change 2: Database

Before, I planned to use SwiftData, but later found out that it is very limited and buggy https://www.reddit.com/r/iOSProgramming/comments/1l0ybez/considering_abandoning_swiftdata_in_my_production/. Therefore, I researched various options and made the switch to SQLiteData, which is based on GRDB.

With this switch, the database actions are very stable and can be used easily in UIKit, SwiftUI, and custom classes. Also, this change allows for creation of migrations, which allows DB schema changes without risking crashes or data loss.

Change 3: Markdown Parsing for Messages

The app currently parses Markdown for message rendering. Previously, I planned to parse HTML using NSAttributedString, but as per Apple’s official warning, the HTML importer must not be called from a background thread and must run on the main thread. This can block other tasks on the main thread, resulting in a decrease in performance.

I am currently researching alternatives or planning to build a custom parser that converts HTML to NSAttributedStringwithout the need for a browser environment.

Issues

When sending messages, I noticed that some messages were duplicated. Upon debugging, I found that when a message is sent to a round, it has a timeout - if the server doesn’t respond within the time limit, the client will try another round.

This was an issue because sometimes the broadcast to the round was successful, but iOS delayed the response going to xxdk, which resulted in a false failure and therefore duplication of the message in the next round.

Currently I have fixed this by setting min rpc timeout to 400ms in custom xxdk client build.
But I am not sure if this is proper fix and therefore researching more and open to feedback.

Screenshots

Some screenshots

You can also find more screenshots by visiting this Proton Drive link.

Next Steps

I can’t wait to get this app into the hands of the community for testing and feedback.

I am currently waiting on some documents, such as Export Compliance Documentation for Encryption, that is required to bring the app to the stores (even Test Flight).

In the meantime, I am:

Doing more testing.
Cleaning up the codebase and writing documentation.
Researching and building a custom HTML-to-NSAttributedString parser for efficient message rendering.

After that, I will make another post requesting a code review.

Source code

You can follow my progress on GitHub - thisisommore/haven-app-ios: IOS haven app · GitHub.

rothbardian · March 25, 2026, 1:11pm

Looks very nice, and kudos for doing the right thing - abandoning sub-optimal paths with sunk cost more than once!