Creat work, bro. I noticed that you are using bark cli to create wallet or fetching data, have you tried this package Bark-ffi swift bindings?
Yep, that’s implemented in the latest code (since last week or so), and allows for having the iOS app (I haven’t fully ripped out the cli from the codebase, that’s a bit further down the to-do list). Still a few functions missing from the bindings, but works great already. Huge thanks to Kumulynja for creating them.
One more update before heading into the holiday time. I spent a lot of time now refining the mobile app, properly porting out all the screens and establishing a mobile-native navigation structure that should feel simple and fluid. Here’s a 3-minute video demo:
And some screenshots (make sure to check the video, it’s usually easier to get a feel for how interactions come together when you see them in action).
Still a lot to do, but I’m pretty happy with it. What do you think? Good direction? Weird? Tired of AI-generated fashion models yet? And the big question, would you use this?
1 Like
It’s hard to say what the best source of truth is given how bark is architected. The infinite time/money answer is to implement a new BarkPersister which explicitly handles cloud syncing of data and ensures what is being read and stored is up to date. Likely with some form of locking to prevent multiple clients attempting to perform database mutating operations at the same time. The simpler answer would be to use barkd on a server/desktop and have the mobile wallet connect to it via REST like people do with Zeus and Zap.
2 Likes
This is looking really amazing, genuinely I’m impressed how unique the style of the wallet is and at the same time how it looks very much like a native Apple app. It’s very slick whilst still suiting some more advanced user needs which I think is an area a lot of wallets tend to struggle with. I’m a big fan of Nunchuk for its advanced feature set however it often lacks in the UX department. It seems you’ve got a good balance right now with Arke.
2 Likes
Happy new year. Thank you for the kind words, Peter.
My next update is more rambling and messy because it’s still a big work-in-progress. But I like sharing regularly even if it’s still uncomfortably rough. This one covers:
- Unilateral exit - first draft of recovering your bitcoin in case the server goes away
- Fee summary - first draft of fee math to make an economic case for users and help them optimize their usage
- Activity - lots of detail revisions to communicate state and user relevance
- Console - some quick thoughts on the changes needed there
As I wrote, it’s a mess. But it should be in a much better state in 1-2 weeks once the tech is wrangled into submission. And with a bit more polish, maybe it’s time for TestFlight soon. Happy to hear any feedback you may have.
2 Likes
Long time no update here. I have been super heads down trying to polish everything in order to get a first TestFlight version out. The UI feels a ton better overall. Still lots of polish to-do and a few small big gaps, but I am way more comfortable with it now.
Something I wanted to share is where I ended up with the Ark-specific language around onboarding, offboarding and unilateral/emergency exits. Generally, I wanted to avoid any sort of technical terminology and give users a super simple framework to work with.
In essence: You have two balances and can move bitcoin between them.
In a little more detail:
- The payments balance is for instant payments and has low transaction fees, but requires a regular maintenance fee (for the refresh).
- The savings balance is slower with high transaction fees, but no maintenance fees.
- You can move money between them
- If there are connection problems, you can get your funds out with a Solo Move (like a regular move, but independently).
So no mention of bitcoin network, Ark network, onboard, offboard, or unilateral/emergency exit. Just a few simple top-level terms that match use cases.
The description for “Move to payments” needs work still.
For the Solo Move, I have some UI stuff in mind that I have not gotten around to. The app definitely needs indicators for when there is not internet and/or no server connection. And, for example, if there hasn’t been a server connection for X amount of time, a migration via a Solo Move can be recommended. Fee estimation is also still missing there. Generally, there should be strong guidance for when to do a Solo Move and when not. But I don’t think it needs the dramatic “emergency exit” label.
I am curious if this sounds intuitive just from reading this post? I certainly find it intuitive when using the app directly. My plan is to go into TestFlight with this approach and then get user feedback.
Let me know what you think.
1 Like
The savings <> payments wallets look nice and intuitive, and I like the term “move” for transfers between the two accounts. But I hate the term “solo move”. I don’t think that’ll help any layman users’ understanding and it’s just another thing to map to existing terms for anyone already familiar with Ark.
Also the descriptions in the UI seems to have the flow the wrong way round (savings → payments) which was confusing me at first!
Emergency exits are something that most users should never encounter, and if they do, it probably is an emergency. And they’re relatively expensive—you don’t want anyone doing one without it being absolutely necessary. So I don’t think it’s an issue to confront them with alarming terminology in warning pop-ups at appropriate times + hide it in sub menus.
I’m not saying it has to be “emergency exit”, I just think using more familiar and/or urgent terminology here would be better. E.g., force move, emergency move, emergency withdrawal.
1 Like
Thanks for the feedback. The exit terminology and UX around it is definitely something that needs to evolve.
Forgot to mention that everyone is invited to sign up for the TestFlight wait list on the website: https://arke.cash
Some things will be a bit shaky, but it will be good to get early feedback.
1 Like
Testing has been going well so far. It’s been an intentionally small group, I’ve had various conversations, and it’s always interesting how every person’s use and experience is so different. Big thanks to everyone who has given feedback.
One of the issues I keep having is that my faucet (short demo video) keeps having problems. Initially it was because I had both barkd running (with a twice daily refresh cron job) and manually interacted with it. But even after I stopped doing that, the VTXO database seems to get out of sync with the server. It’s gotten better, but still problematic. Not really sure how to address this one.
I also pushed out a second version to TestFlight with lots of tweaks and fixes that also updated the refresh to the delegated process, which majorly improved that user experience. Great work with hArk there.
Big additions in the next version will include a custom BDK wallet with onchain history, localization support, a proper color palette, fixes to BIP-353 handling, and lots of other small stuff. After that, I think the other big piece missing are notifications, which is a bit more complex due to the server relay I need to set up, and I need to plan some dedicated time for that. Fingers crossed that after that it is mostly optimization and polish (which is always tedious and takes a lot of time).
I’ll keep opening up TestFlight little by little during that time. There’s also a roadmap page on the website now that explains the project goals and steps a bit (I’m reserving the right to change that stuff at will at this early phase). Curious what you make of all this. Let me know if you get a chance.
1 Like
We’ve been heads down on fixing the issue that was causing the faucet failures, and the fix is now in the imminent beta.8. Let us know how that goes.
Nice one on getting the delegated refreshes in Arké already. That turnaround is fast. Probably the first delegated refresh implementation to make it into an app ever!
Hopefully the new unified mailbox should make adding the notifications pretty quick.
Will get on doing a new round of testing on the TestFlight v2 soon and drop in some comments again!
1 Like