Aragon native mobile app

Tasit Labs would like to build a proof-of-concept native mobile app for Aragon.

The primary motivation is to make it as easy as possible to participate in Aragon votes or to create new votes (including votes to add new DAO members). I know I personally end up setting reminders using Siri to invite people to the DAO for my meetup group the next time I get back to my laptop, and that makes for a clunky experience.

We’re thinking that this would be a standalone native mobile app, not a PWA (progressive web app) within a dapp browser app. We would build it using React Native so that it would work on both iOS and Android.

It’s T.B.D. whether this project can fit within the budget of the Community Funding DAO or if it’s a better fit for Nest.

Past experience
Here’s an example of a 3rd-party native mobile app we recently built that lets you buy Decentraland land and estates:

Decentraland app code

I could go into a lot more detail here, but I’d like to keep this forum post short to get people’s initial reactions to the idea itself.

Tasit website
Tasit GitHub


Thanks for posting this!

My comment is possibly a bit tangential but interested in getting your perspective on this. I am not a programmer and don’t wish to start a flame war over languages so feel free to speak frankly about this :slight_smile:

I read an article a while back about how Airbnb moved off of React Native, they had some quite interesting conclusions about it that led them to make this decision. How do you think their conclusions would affect your choice to use React Native here?

For context:

Thanks for a quick response! Yep, the blog post is a great read that made a big splash when it first came out.

The TL;DR of that five-part blog post is that ( A ) trying to add some React Native into legacy iOS and Android codebases ( B ) with associated pre-existing teams ( C ) at the time they originally introduced it didn’t work out well for them.

For a new project that’s in React Native from day one starting today, the conclusion would be different, and I think the Airbnb team would agree. React Native is seeing lots of adoption from engineers who are just starting out, and that’s a good leading indicator of where things are going.

Especially when your front-end dapp is already in React, which opens up the possibility of sharing code between the web app and the mobile app - something that benefits Lorikeet too.

Also, given that it’s a crypto-related app, using a common codebase between iOS and Android derisks the scenario where you spend a lot of engineering time on a new feature for one platform and then the app update is censored on that store. With it written in React Native, at least the users on the other OS can still benefit from the engineering work while the censorship dispute is resolved.

That last point touches on a whole separate topic, but that’s certainly something we can discuss in more detail too if you like! Here’s the quick version of my view on the censorship question: ( A ) The experience can still downgrade gracefully to a web dapp, so the user isn’t truly censored even in the doomsday scenario. ( B ) Over time, an increasing wave of dapp submissions should help convince Apple and Google to censor less and embrace permissionlessness (especially when users can do the same things with worse UX inside of a web 3 dapp browser app). In the meantime, they’re accepting most crypto apps as long as you’re not trying to scam users.


@light Do you have any ideas on how to make sure the heavy users of existing DAOs see this and get a chance to weigh in? I’d love to get their thoughts in particular. Thanks!

In my opinion I think we should prioritize making it a PWA :smile:.

Would you mind listing the pros and cons of native apps vs PWA?

Sure, I’ll work on putting that list together today or tomorrow!

A recent announcement from Expo (an SDK on top of React Native) means that we may not need to pick a build/deployment target (native iOS vs. native Android vs. PWA) just yet or commit to only targeting a subset of them, which is great.

“We recently announced beta support for creating progressive web apps in addition to native Android and iOS apps from Expo projects. With SDK 33, you will be able to create apps for all three platforms from one project.”


1 Like

In my opinion I think we should prioritize making it a PWA :smile:.
Would you mind listing the pros and cons of native apps vs PWA?

@danielconstantin Here you go!

Notes about using Expo for a shared codebase for PWAs and native apps as mentioned above, before we dive into pros and cons of PWAs

Expo’s support for targeting a PWA for builds is built using react-native-web. Nicolas Gallagher built RNW (react-native-web) while also using it to create the Twitter Lite PWA.

Major League Soccer, Flipkart, Uber, The Times, and DataCamp have all since built mobile web and desktop apps around RNW. Expo also consulted with Facebook (the original company behind React Native) to get a second opinion on web support.

So while this Expo feature is still in beta, it wouldn’t be untrodden territory to use a react native codebase to build for a PWA environment.

Time for the pros and cons of PWAs

Here are the pros and cons below. Putting the list together took a little time, so I’ve undoubtedly included some quoted or paraphrased text for some of these points without attribution - sorry about that.

Another caveat is that PWA tech is coevolving along with the platforms it runs on, so some these pros and cons may change soon from cons to pros or vice versa - or already may have changed.

Pros of PWAs

  • Since they’re available over the web, no app store can censor them
  • One less step in the install process compared with a splash web page that links to the app store page
  • You can use SEO techniques in a more straightforward way with a PWA
  • All clients are automatically on the latest version (with a few caveats around caching) without prompting users to update
  • Catches a wider swath of less engaged users that may be annoyed by having to download an app
  • Saves storage space on phone
  • If the user is trying to download it when not on wifi, it uses less data than if it were a native app
  • "Try before you buy" from an installation perspective

Cons of PWAs

  • Mainstream users aren’t used to this flow yet. That’s one of the most significant challenges on iOS as there will be no prompts or invitations to save it to your home screen from Safari (known as Web App Banners on Android). So the user has to go to your PWA URL somehow within Safari and then manually press the Share icon and then “Add to Home Screen” - hopefully that will be in the first four share icons that show up before the “fold”. There will be no indication that a website you are visiting is a PWA.
  • It is still very early days for PWAs, so new bugs impacting UX will surely crop up as mobile browsers change, mobile OS’s change, etc.
  • Users risk losing data, including a private key if the app experience uses a burner/ephemeral account as a delegate account or with a contract-based account. If the ephemeral account private key is stored in IndexedDB with a persistent setting (and uses the Web Crypto API), how do we message that to users that they might lose it if they use other web apps too much? There are lots of subtle rules governing when space is cleared up, even if the storage has been set to be persistent for the PWA.
  • There are many features that a PWA cannot access on the device, which makes it lag behind native apps for feature parity. PWAs cannot access a device’s NFC, or near-field communication. PWAs also cannot access a device’s Bluetooth (on iOS), proximity sensors, ambient light, advanced camera controls, geofencing, wake lock, contacts, and more, which could make the app less personal for users. Can’t access fingerprint scanner / Face ID, something that’s important for crypto apps. Also can’t access ARKit, altimeter sensor, battery information.
  • Although it is a benefit that PWA does not follow the long process of app downloading like native applications, they also miss out on a large chunk of users who primarily search for apps on the app store.
  • Less familiar install flow for non-tech-savvy users - and that’s hopefully part of the audience Aragon would like to reach in order to go mainstream.
  • Limited performance for computation heavy operations – although WebAssembly is improving this
  • On iOS, only Safari lets you access service workers and the ability to add to the homescreen (bad news for Chrome, Firefox, Opera, etc. users). Also Service Workers can be disabled from Settings under Experimental technologies (it’s enabled by default)
  • With more and more social media companies making their own in-app browser, it is getting difficult to promote PWA experience on social media because it won’t open in the full Safari app.
  • No ability to have a standard splash screen
  • On iOS PWAs in the history don’t have any screenshot so they all look like white screens unfortunately when you’re scrolling through other apps you have open.
  • On iOS password managers behave in a buggy way when trying to log in
  • The app can store offline data and files only up to 50 Mb on iOS (on Android it doesn’t have this limitation)
  • Native apps appeal to more engaged users that have committed to regularly using that particular app (based on statistics of user behavior segmented between mobile web apps and native apps).

Here’s the associated Nest proposal for this:

Hey @pcowgill, I have been thinking about an app and how it could improve participation.
One of my main thoughts was around UX and how we could use agile to see what would work best before coding. Taking into account that probably will be the base of future implementations, seems like a good idea to start as close to a global maximum (if such thing exists) as we can. Any idea on how to move forward with this?
For me motivation testing and usability testing could really pay off in the long run.
Adding some gamification could go a long way imho.


Expo sounds really cool in that you can target all three platforms.
We have the aragon-desktop project which does the same, but with electron.

Do I understand correctly that this is a “wrapper” around the Aragon Web GUI so we can leverage Android/iOS/PWA features (viewing offline, better caching, etc.) or is the plan to re-implement it all in React Native?

1 Like

@francopetra That’s great to hear! Yep, I think if there were a budget for UX design research that would be really cool - I wonder if the Aragon team has any links they can share of any work they’ve already done related to this?

@danielconstantin I’m thinking it wouldn’t be a wrapper around the web GUI - I was picturing re-implementing it all in React Native. But that’s far less work than it might sound like at first.
This would involve copying and pasting components in from the React app where appropriate and converting the styles over to use React Native StyleSheet (similar to many css-in-js packages for the web).

The Aragon experience was originally designed for a laptop-sized view, and I think some things could be improved when designing around a smaller screen from day one. I think in the short-run this is a situation where two loosely coupled code bases allows for better freedom to iterate and innovate. And then on a longer timescale identifying best practices from both mobile and web components and including them in lorikeet or a shared Aragon component library that works in either env in a DRY fashion could be interesting to explore.

Given that we’re talking implementation details, hopefully that means there is interest from the community in an Aragon native mobile app (or apps) in a broader sense?


I just created an AGP related to this discussion!

1 Like

@pcowgill Not sure if it’s of interest, but there’s an open RFP for a mobile wallet app that seems somewhat similar to this proposal