react-native-safe-area-context package was patched to return View instead of native RNCSafeAreaView that doesn’t exist for desktop. That allowed us to use navigation.
fixed few functions in react-native-status
Packages blocked using shadow-cljs.edn:
react-native-touch-id
react-native-image-resizer
react-native-dark-mode
@react-native-community/netinfo
react-native-reanimated
react-native-redash
react-native-webview
quo/animated namespace functionality was fully mocked because it relates on react-native-reanimated and react-native-redash (both not supported for desktop)
quo/gesture-handler also mocked
qrcode commented everywhere because relates on react-native-svg which is not implemented for desktop.
setInternetCredentials commented out for keychain - this means that Save password is disabled for now
The biggest obvious problem is a performance, especially on lists. Scrolling quite small list leads to significant cpu and memory consumption. Can’t say if that will be easy to deal.
Our opinion: it is possible to use react-native-desktop-qt for Status Desktop but performance problems should be addressed. Also we tend to think that desktop repo should be separate from mobile. It should reuse logic and could reuse some components but attempts to reuse full UI will slow down everyone. For desktop it would be easier to create own UI taking into account react-native-desktop-qt restrictions rather than chase mobile UI.
macOS: Dropbox - Status.dmg - Simplify your life
→ Note: first run, need to right click → open (due to new apple requirements for notarization); if in the applications folder, then you need to manually open the folder, right click → open
Notes:
Ensure there is no existing status app running (like status-rn-desktop, ios simulator running status mobile, etc…)
Ensure firewall is allowing the status app
There is a ~2 second lag moment after login, we’re currently working on optimizing this. (It’s due to wallet requests we need to optimize)
Browser not working on linux yet. (On mac it’s experimental)
In 4k / high resolution screens the fonts might be blurry (something we’re currently working, seems to be a QT config)
Stickers will display, sticker selection is WIP
Video: desktop_beta.mov - Google Drive
→ Note: the video is completely unedited, => sometimes there are long pauses which is me grabbing my phone or looking in etherscan for some random ethereum address for the wallet <=
It’s possible, from my tests Qt on Android is kind of slow. I am still waiting on a PinePhone to see how it would fair on mobile linux if it does then freedom respecting hardware, operating system and app would be a great combination.
I have to say that this has been impressive progress. The desktop team have been absolute executing machines. This demo has made me really excited about the future.
Thank-you very much all involved.
An attempt to recap and wrap up a month of investigation and prior discussions with soft conclusions. So we can close this topic with consensus and keep building awesome stuff. Please share whether you think these are valid conclusions.
Two experiments were run
They differed in technology stack, using react-native-desktop-qt vs nim-qt, to develop a Desktop client, allocated resources and design support
Other stacks were used during an earlier experimentation phase, e.g. electron see reply by Iuri, but dismissed and not actively worked in over the last 30 days
The Desktop implementation using react-native-desktop-qt focused on chat and porting the react-native UI currently in production on mobile; The implementation using Nim-Qt focused on the chat and wallet features mimicking Status mobile logic based on specs
Both teams delivered a demo bundle in 1 month time (see above)
Learnings
Understanding of ease/complexity to rebuild logic in nim-qt
Understanding of ease/complexity to port react native to desktop
There’s work to do to improve cross-team communication and decision making I think Stimbus discourse went better. Communication around implementation decisions for iOS notifications are also a prime example. There’s no golden ticket here. Transparent communication and decision making requires continuous effort, to push and pull information from everyone involved. Kudos to @oskarth and @cammellos for being strong advocates of this.
Soft answers/conclusions
Desktop team will continue to develop a Desktop client using nim-qt, as it has emerged as a solid choice and helps with Nimbus integration that the team will also lead in the coming months.
Next steps for rn-native-desktop are to be decided by the Core Mobile team. There are two decisions that need to be made:
Should work on Status Desktop, built with the help of react-native-desktop-qt, be continued? No, nim-qt is showing good results and has a team working on it. At the same time, Core Mobile team needs to focus on acquisition and user facing features and can use all it’s core contributors for this
Should react-native-desktop-qt technology development be supported? No, not if it’s not used in Status
Thanks to @volodymyr.kozieiev for fact checking how I describe the different technology investigations and formulating decisions that need to be made at this point.
Please share whether you think these are valid conclusions.
(see above)