1. SN works
My main concern was if the SN posseses all the required ingredients for creating a real life app. Well, it does.
2. Native bindings are hard to use directly and there is a need for a wrapper lib
I did not used the safeapp because it contained a lot of statics which interferes with the dependency injection, unit testing and thus CI. Instead I have created few layers of abstraction. The idea is (1) To insulate the developer from changes in the lower layer (since the API is still not stable and it will change); (2) To create convenience classes that are easy to use.
Currently the zignals app have following layers (starting from bottom):
- Native bindings - this is the java “bridge” to the rust code. It is provided by the SN team
- Prospero lib - fancy named pure java library that provides mostly interfaces like KeyValueStore wrapper around mdata and also wrapper exceptions for the errors like InvalidEntryActionsException, KeyAlreadyExistException, etc.
- prospero-safe-alpha-2 lib - contains implementations of the interfaces specific to the alpha-2. When we move to alpha-3/flemming/maxwell this lib will be replaced,
- prospero-safe-alpha-2-android - contains android specific classes for bootstraping like ProsperoSnRealInitialisationAndroid and ProsperoSnMockLocalInitialisationAndroid.
- Zignals lib - pure java library that contains the zignals functionality, i.e. it can be used potentially not just for android but also for desktop and CLI.
- Zignals app - contains the android interface to the zignals lib
Probably similar set of layer should be used for all apps.
Weight distribution:
- Prospero lib - 1020 LOC
- prospero-safe-alpha-2 - 2306 LOC
- prospero-safe-alpha-2-android - 43 LOC
- zignals lib - 1280 LOC
- zignals app - 3026 LOC
As a rough estimate I expect that fully featured:
- prospero lib will grow to about 10 KLOC - with 200 lines per day = 50 days, 2.5 months
- prospero-safe-alpha-2 - 20 KLOC - 100 days, 5 months
- zignals lib - 10 KLOC - 50 days, 2.5 months
- zignals app - 40 KLOC - 200 days, 10 months
3. Documentation
One of the main problems is the current lack of documentation. I expect that when the API is stabilizied this problem will be fixed. Most important at first will be documenting what errors may happen during a (NativeBinding’s) method call.
4. Safenet debug server (local)
Currently we have mock/non-mock. Mock is for local, non-mock for alpha-2. The problem is that for some apps we will need a SN server that simulates the network and in the same time it is local for the devs and testers group. The reason is that currenly we have 1000 PUTs cap per account and it is not enough for high throghput apps. Even if that limit is raised - there is no need to burden the alpha-2 net if there is a option for local SN server.
5. Open sourcing
Initially I meant to publish the zignals app and libs on github but later decided that probably it is not good idea at this time. From my experience with previous open source project I know that each published repo requires a lot of time to support it even there a relatively few devs using it. Currently I don’t have that time 
Probably I will publish it when we are using Fleming, the API is stabilized and the zignals app and libs are somewhat more mature.
P.S.
I am amazed by the work that the core team is doing. The entire SN concept is mind blowing and I can hardly imagine how hard is to implement it. Great job!
