-
Notifications
You must be signed in to change notification settings - Fork 1
Technical Analysis
It makes sense to utilize a cross-platform framework for building the application in order to get support for multiple platforms out of the box from a single code base. Implementing a purely native application (i.e. Swift for iOS, Kotlin for Android) would double the amount of work required to support each platform. Additionally, some frameworks provide support for web and desktop so this could potentially become a universal UI for Bisq, not just for mobile.
There are numerous frameworks available so an evaluation and comparison is necessary of the most common/popular frameworks, for which I found the following:
| Framework | Supported Platforms*
|
Language | License | Mature | Popular | Active Development | Native UI Components |
|---|---|---|---|---|---|---|---|
| React Native | Android, iOS | JavaScript | MIT | ✔️ | ✔️ | ✔️ | ✔️ |
| Flutter | Android, iOS, web, desktop | Dart | BSD-3-Clause | ✔️ | ✔️ | ✔️ | ✔️ |
| Ionic Framework | Android, iOS, web, desktop | JavaScript | MIT | ✔️ | ✔️ | ✔️ | ✖️ |
| Xamarin | Android, iOS, Windows | C# | MIT | ✔️ | ✔️ | ✔️ | ✔️ |
| Cordova | Android, iOS, Windows | JavaScript | Apache 2.0 | ✔️ | ✔️ | ✔️ | ✖️ |
| NativeScript | Android, iOS | JavaScript | MIT | ✔️ | ✔️ | ✔️ | ✖️ |
| Framework7 | Android, iOS, web, desktop | Javascript | MIT | ✔️ | ✔️ | ✔️ | ✖️ |
| Meteor | Android, iOS, web, desktop | Javascript | MIT | ✔️ | ✔️ | ✔️ | ✖️ |
| Kotlin MultiPlatform (KMP) | Android, iOS, web, desktop | Kotlin | Apache 2.0 | ✔️ | ✔️ | ✔️ | ✔️ |
* Native support, no external frameworks or plugins required.
Based on the above comparison, the following conclusions can be made:
- If we also want to support web and desktop platforms, in addition to mobile, that limits our selection as not all frameworks support them natively. Some may have external frameworks or plugins to provide support for additional platforms, but that poses a potential risk of abandonment or incomplete support.
- A lot of frameworks just use a web view as a shell and the whole app is a pure website. This will always feel subpar compared to a native app. It would be wise to chose a framework that has a native UI experience.
- For Xamarin, .NET or C# development is required so may not be the best choice for our potential contributor base. Also, it would likely rule out the potential for integrating a Java-based Bisq instance into the Android mobile client.
- For KMP, a majority of shared code is written in Kotlin with a small UI layer written in native code (i.e. Swift for iOS, Kotlin for Android). This would give us the best of both worlds (shared code and native experience). The extra step of having to develop a thin UI layer in separate languages is likely worth while and should not be too much added effort.
As a result, it makes the most sense to utilize Kotlin Multi Platform as it gives us the most benefits and should meet all our needs.
For the native code (i.e. Swift for iOS, Kotlin for Android), there should be no problem finding necessary libraries. The only concern may be Tor support on iOS. However, other Bitcoin/Lightning wallet apps have integrated Tor support so it may not be an issue. A couple such libraries that provide Tor support are:
For the shared code base being implemented in Kotlin, there should be no problem finding necessary libraries.
A major concern, particularly with Bitcoin software, is malicious third party packages being included inadvertently. Since KMP uses Gradle as its build tool, we should be able to utilize Gradle witness to verify dependencies, like is done with Bisq.
When developing a web application, there are security risks to consider such as those detailed by the OWASP top 10. These risks will need to be considered during development and undergo in depth security testing before we could be confident releasing a web application.
Ideally, we should incorporate the designs provided by Pedro - which are described in UX Design.
Communication will be done via the GRPC API using a localhost socket or over Tor to the Bisq client using password authentication. This will allow running Bisq either locally or remotely. To eliminate encryption concerns, there will be no support for non-localhost socket connections.
In terms of the pairing process, the user would need to input the Tor address (if running via Tor) and port of the Bisq client. This can be cumbersome and error-prone. Therefore we should utilize scanning a QR code from the Bisq desktop app, or when running a headless client we could generate a QR code using something like qrencode or some other library.
We should be able to utilize the existing mobile relay node to send iOS and Android push notifications without any changes required to the service. The only thing that should change is the method by which we send the device token and encryption key from the mobile app to the Bisq client. The existing method is done by scanning a QR code generated by the app into the Bisq client (or by emailing it from the app and entering it into the Bisq client). We should be able to utilize the GRPC API to send this info, though support for this will need to be added to the API.
In terms of supporting non-Google Android devices that do not have the Google Play services installed (i.e. CalyxOS, GrapheneOS, LineageOS, etc) which are unable to utilize the Google push notification service, we may be able to utilize something like https://unifiedpush.org/.
A truly independent app without the need of an external Bisq client is only possible on Android, since it is Java based. Integrating it into iOS would require rewriting the Bisq client in another language that is portable to iOS - this would be a major undertaking and likely not in scope for this project.