I can see that the sentiment is generally negative towards this proposal with the main concern being the amount requested. Therefore, it saddens me to say that I don’t see any alternative than to withdraw it. I’d be happy to support anyone who wanted to pick it up but that support would only be to hobbyist level where I could find the time.
1 Like
expanded response from AI bro that largely agrees with @ardocrat reply earlier about what needs work to make grim work:
No, it’s not ready for iOS. There is zero iOS-specific code or configuration in the project. Here’s a concrete breakdown of what it would take:
1. Platform Scaffolding (Missing Entirely)
The app has two platform modules: android and desktop (selected via cfg(target_os) in mod.rs). There is no ios variant. You would need:
- A new
src/gui/platform/ios/module implementing thePlatformCallbackstrait (camera, clipboard, file picking, etc. — see mod.rs). - An Xcode project (similar to the android directory) with an iOS app target, provisioning, entitlements, etc.
- An iOS entry point. Currently main.rs gates
real_main()behindcfg(not(target_os = "android")). iOS would need its own path — likely a#[no_mangle] pub extern "C"entry called from an Objective-C/Swift bootstrap, or using a Rust framework likecargo-mobile2.
2. GUI/Rendering
The desktop path uses eframe with wgpu + Glow fallback (Cargo.toml), while Android uses eframe with glow (Cargo.toml). For iOS:
winitdoes support iOS, but you’d need the right feature flags (similar toandroid-game-activityfor Android).eframe/eguican render on iOS via Metal (throughwgpu) or OpenGL ES (throughglow). You’d add acfg(target_os = "ios")dependency section choosing one.- The
nokhwacamera crate has no iOS target today — only Linux (V4L), Windows (MSMF), and macOS (AVFoundation). You’d need an alternative (e.g., direct AVFoundation bindings viaobjc2or a Swift bridge).
3. Tor — What Would Break
3a. Arti (Pure Rust) — Mostly OK
The core Tor client uses arti-client v0.41 (pure Rust). This should compile for aarch64-apple-ios as all dependencies (ed25519-dalek, curve25519-dalek, tor-* crates) are pure Rust. However:
tls-api-native-tls(tor.rs) wraps the platform’s native TLS. On iOS this means Security.framework, which thenative-tlscrate does support — so this should work.tor_rtcompatwithtokioruntime — works on iOS.fs-mistrustenforces strict Unix file permission checks. iOS sandboxing uses different permission models. You’d likely need to relax or disablefs-mistrustchecks for iOS, or patch it to understand the iOS sandbox.
3b. WebTunnel Bridge — Major Problem
This is the hardest blocker. The project compiles a Go binary (webtunnel) at build time via build.rs and webtunnel.sh, then embeds it with include_bytes! and writes it to disk at runtime to be executed as a separate process (tor.rs).
This will not work on iOS because:
- iOS does not allow launching child processes / external executables. Apps are sandboxed and cannot
execorfork. - You cannot ship a Go-compiled binary inside an iOS app and run it.
- Fix: WebTunnel would need to be reimplemented as an in-process library (either as a Go library compiled to a C-callable
.a/.frameworkviagomobile, or rewritten in Rust). The pluggable transport would need to run as a thread inside the app, not as a separate process.
3c. Onion Services & Background Networking
The code runs Tor onion services with a reverse proxy (tor.rs). On iOS:
- Background execution is severely restricted. iOS suspends apps after ~30 seconds in the background. Onion services require persistent connections. You’d need to use iOS Background Modes (e.g.,
voip,audio, or the newerBGProcessingTask) and accept that the service will be interrupted. - Network Extension framework — Apple may require Tor networking to be done in a Network Extension (packet tunnel provider), which adds significant complexity.
4. Other Platform Dependencies
| Dependency | iOS Status |
|---|---|
dirs (filesystem paths) |
Needs iOS-specific paths (NSDocumentDirectory) |
arboard (clipboard) |
Not available on iOS — need UIKit clipboard |
rfd (file dialogs) |
Not available on iOS — need UIDocumentPickerViewController |
interprocess (IPC) |
Desktop-only, but already gated behind cfg(not(android)) |
local-ip-address |
Should work |
ring (crypto) |
Supports iOS |
Summary
| Area | Status | Effort |
|---|---|---|
| Xcode project + platform module | Missing | Medium |
| egui/eframe rendering | Supported in theory, needs wiring | Medium |
Camera (nokhwa) |
No iOS backend exists | High |
| Arti Tor client (core) | Should compile | Low |
fs-mistrust permissions |
Needs patching for iOS sandbox | Low-Medium |
| WebTunnel bridge (Go binary) | Blocked — cannot exec on iOS | High (needs rewrite to in-process lib) |
| Onion service persistence | Conflicts with iOS backgrounding | High |
| Clipboard, file picker, etc. | Need native iOS implementations | Medium |
Bottom line: The Rust Tor client (arti) itself is close to working, but the WebTunnel Go binary is fundamentally incompatible with iOS’s no-subprocess policy — it would need to be turned into an in-process library. Adding the broader iOS platform support (UI, camera, clipboard, Xcode project) is a substantial but straightforward engineering effort. The backgrounding restrictions for onion services are an ongoing design challenge with no perfect solution on iOS.
================================================
Seems doable I guess without Tor for sure, and I think Tor is possible (but I guess not bridges). Skylight wallet for Monero has an iOS app that uses Tor:
And looking at release notes it is using work done by Stack Wallet’s Arti integration, so Tor itself seems like it should be possible…
1 Like
I think it’s still worthwhile. The app is beautiful and it fulfills a need. Why not just put what you have on github so everyone can contribute, put it on the App Store under your company, and request funding for the Apple Developer account for the next 10 years ($1000 USD)?
Steps are:
- Download Xcode
- Download iOS platform
- Sign in account inside Xcode and create team
- Enable developer mode at iOS
- Install the app
- Mark developer as trusted in Settings > General > VPN & Device Management
1 Like
Realistically, how bad is it if you use Grin without Tor?
If it’s not recommended to ever do that, then Grin is very tightly coupled with Tor?
I think it just depends on your threat model. For most people it is probably fine. The number of people that use Bitcoin or Ethereum or even Monero over Tor is probably in single digits or fraction of a percent…
Main reason is ability to expand endpoint without server, Mwixnet depends on Tor hard currently
Tor is CIA honeypot, sponsored by DARPA, all exit nodes are under monitor by creators of internet.
*Sorry for off-topic*.
That’s lowkey what I think too lol. So for Grim then, seems like launching on iOS is fine without Tor…
Reticulum is so cool, I read their manual everyday before the sleep. New version updated today btw. They recommend to use i2p for some reasons.
3 Likes
I do not like the tone you have towards other community members. Neither do I think you have any right to criticize anyone for using AI since you are a self proclaimed Vibe coder who produces AI slob all the time 
Why were you silent when there was such a proposal from Unstoppable wallet, yet now you complain?
I know you like trolling and creating dissent in the community, but really, to what end?
Just for the lols? If that is what you like to spend your energy on, please do it as part of your “community fork”. If you want to be active here, play by the rules, stay polite and constructive.
@Anynomous you are correct, I am a vibe coder, the difference is I don’t ask 40k for my work. No ones paying 40k for acouple api calls lol
The original poster had already withdrawn his request. You can feel free to close this thread instead of using it as a platform to attack syntaxjak for pointing out the obvious scam. My tone? Give me a break pal!
It’s become pretty common these days to use AI when writing code. At the end of the day, what really matters is the final result. If the code is safe, secure, and genuinely useful for the user, I don’t see any problem with paying the developer for their work - even if they used AI to help create it. Putting all the pieces together, compiling everything into a coherent project, and thoroughly reviewing the code are still crucial steps.
It would be great if Wayne kept working on his wallet. The UI is excellent. It might be a hobby project, so it could take a while to finish, but once it’s ready, we as council members could consider donating a certain amount to support it.
2 Likes
@bruges imagine paying thousands of dollars for art generated by ai verses paying thousands of dollars for hand painted art the took hundreds of hours to complete.
Originally, code had to be manually typed out, line by line, taking thousands of hours over hundreds of days, this is why code use to cost 40k to produce. Times have changed. No one should be asked to pay 40k for a user to make a handful of Ai api calls over a couple dozen days!
If Wayne was paying for the ai service he used, it might be fair to ask compensation for that, so maybe what, like 50 bucks seems fair no, plus how many hours did he work on the code? 20 hours at 20 bucks an hour? So that another plus 400, so ya, in total, probably about 500 bucks worth of time and material. That seems to me to be a fair compensated. Why 40k in though?! That’s a scam no?
The way you say things does absolutely matter. Within this project there has been a history of community members being disrespectful to developers leading them to walk away. If you care about grin 
, take care of the people who commit their time to it.
If you are overly impolite and a developer feels attacked or shamed, that will often lead to them walking away and perhaps even abandon the project completely. Creating a polite, constructive environment makes any project more welcoming and successful.
Wayne produced a working user friendly wallet in his free time, I think that should earn some respect and not lead to you trash talking him. If you criticize the code quality or the asked amount, that is fine, just do so politely.
I’m happy to pay you $100, from my own pocket, for creating an iOS wallet for Grin.
1 Like
@bruges yeah, plus time, so if it took 20 hours to complete that’s fine, give him an extra 1k. So ya somewhere beteeen 500 - 1000 dollars seems pretty fair based on time and material.
@bruges it would take me 25 minutes to clone this repo and run it through codex to update it to a working order, remove tor functionality, reskin it and rebrand it… would be the quickest hundred bucks I ever made lol. Do yall forget we already had a very nice iOS wallet for grin? No one used it, that’s why we should have payed to integrate into a pre-existing, already popular wallet…
1 Like
Just a few more words on this topic as it has been playing on my mind. Building an iOS app for Grin had been something that I wanted to do for years. It was part of the reason why I learned SwiftUI in 2023. The challenge always was finding the time. I knew that to make it what I wanted it to be would require a good amount of commitment. As I recently discovered the advancement in capabilities of AI-assisted coding especially with Opus 4.6 in a CLI, I realised there was an opportunity to build a prototype. I sacrificed some of my own time in an attempt to share my vision of what could be possible which I think I did. I knew, though, that a lot more was required to get it to a place that the project deserved. My background is building AV control systems for the world’s top investment banks, so I know the importance of building reliable software. Therefore, it’s something that I would have needed to have done meticulously and not with a few AI prompts. I don’t think much is discussed around the use of AI in Grin other than a few people experimenting here and there. I think sentiment and understanding is mixed in the tech industry as a whole and as a result, many conversations haven’t yet been had. My personal view is that I see AI as a tool and like any tool, it can be used to create art or trash, depending on the skill of the wielder. That being said, taking on this project was something that I already wasn’t 100% about and I felt that I wasn’t able to persuade any further than I tried to with the prototype. I knew that things could go wrong that could damage not only my reputation but the success of the business I am building. £38K isn’t a life changing amount of money for me but that was an amount that I was prepared to accept to sacrifice for. I think Grin as a project has a lot more to figure out than what to spend the fund on but I think that is best discussed in another post. I just wanted to share a little more about how I felt because I don’t think that was expressed well in the proposal. I hope that more people step forward with ideas for the project. I’m liking the work being done by Ardocrat and Wiesche to strengthen the network. I’m hoping that the project can attract new developers and new interest to keep the project alive.
2 Likes
Please go ahead and do it, that would be a productive contribution to Grin. Once it’s ready, publish it on the App Store and Play Store. Then calculate the total hours you spent and multiply by your hourly rate. That amount can serve as the basis for requesting a donation from the council.