About messaging, we started using PSS (https://swarm-guide.readthedocs.io/en/latest/dapp_developer/index.html#pss) in our first PoC, that offers real-time messaging capabilities using the Swarm network.
The downside is that it requires running a Swarm node so until adaptive nodes (ethersphere/SWIPs#12) are supported, we're using a Swarm gateway and feeds (https://swarm-guide.readthedocs.io/en/latest/dapp_developer/index.html#feeds) for asynchronous communication.
Regarding end-user traction there's a classic bootstrapping problem between the constraints of getting users in order to be interesting for developers, and having developers create compelling apps to attract users. Eventually we want to build compelling apps ourselves, but for this we need to build a solid foundation at the platform/SDK level.
One of the difficulties in that regard is moving from proof-of-concept implementations to "future-proof" protocols we need to define, implement and experiment with. This is something we're doing with the wider Swarm community because we hope these protocols can be used not only in Mainframe OS, but generic to decentralised apps using Swarm.
About supporting the
bzz:// protocol it's not something we intend to do in Mainframe OS because the protocols we aim to provide are higher-level, but it would be nice to have it supported in browsers such as Brave for example, where it could be more relevant.
Apps are built using Web technologies and run in a WebView, but yes they need to be packaged so the assets are downloaded by Mainframe OS when the app is installed.
Eventually we would provide a marketplace that would be useful to discover apps, but apps can be installed simply by providing their unique ID.
At the moment the platform and SDK are not future-proof, this is an ongoing process made of different moving parts such as the infrastructure (Ethereum and Swarm) possibilities and limitations, defining data structures and obviously the security constraints.
I think the current state of Mainframe OS and the SDK is good to get familiar with the ecosystem and build test apps, but they will likely be subject too many changes before we reach a stable version. I don't think any work you could to today would be rendered useless from a version to the next as the interactions flow should mostly stay the same, but actual calls to the SDK would likely need to be updated.
There has been no audit so far but it's something we'll likely do when reaching a first stable version.