…continued from another thread, in which @dellams asks:
I think the network usage is the more critical issue, especially with the prevalence of data plan limits on mobile. This might not seem a big issue with the clutter example, but what happens in a world of holochain apps that are constantly buzzing the network with packages?
@dellams @sonicviz I don’t want to derail the conversation too much by expanding on the mobile questions, but I do have one comment: both Apple App Store and Google Play Store disallow apps that spawn long-running background processes. This is to save on battery usage. This means no background DHT chatter (or any app feature that relies on node-to-node messaging, such as notification pings) unless you actually have the app open and on-screen. You could release a hApp via the F-Droid store that stays connected to the DHT even after you close it, but most people won’t know what the heck F-Droid even is.
And yes, there would be data plan usage to worry about too.
That’s why I think that maybe the way to go mobile for now is with PWA, connecting directly to Holo… It should be a lot easier this way, it’s accessible and downloadable from a URL, and using Holo guarantees data availability in small networks (like for example a chat gorup).
Ok thanks guys. 
I like the PWA and looks useful for future use…
But I am thinking more of how I will get my Unity game to run on a phone talking to hc? I guess this could still use Holo somehow? But I think Holo only works in a web browser? My game is a standalone unity app so it will not run in a browser. Is there a way I can still route traffic through the holo network? I presume under the hood Holo just uses normal HTTP traffic so this should be possible? Is there anyway of seeing the code that does this so I can then use it in Unity?
I created my HoloNET .NET client to get Unity to talk to hc but I guess I will not be able to use this on a phone then?
As a last resort I could get unity to compile it to WebGL and run it in a browser on the phone but I would rather avoid this if possible…
Maybe I should create a separate topic for this somewhere on the forum? Where is the best place? Be good to open up this discussion to everyone else…
Yes, it seems like this is a very in depth topic, maybe create a new discussion to explore all the possibilities. I think the right direction to go is Holo, since it theoretically meets all the requirements. I know that Holo maps domain names to holochain apps (or sth like this) so maybe you have to setup a fake domain or sth like that, but it should be possible.
Here I found an in-depth explanation: https://github.com/Holo-Host/holo-router
Great thanks will check that out…
I’m leaning towards Holo for most mobile stuff too. I would love to see native installed apps using Holo; right now there’s no drop-in libraries to support it though. I’m picturing something that emulates the Chaperon client-side library, only in native Android or iOS code. It will have to:
Mmm there’s things like ionic or react native, that people already use in normal projects, which can “export” web technologies to native applications. Ionic for example does this by encapsulating the application in an “embedded” browser, but it’s still web technologies. So the integration seems pretty easy
hmmmmmmmm, in that case that sounds like an easy path. Can these webview-based apps do iframes? I’m guessing so.
I think so. But what I need is it to work with unity so I would need to do something like Paul suggests above…
I can give this a try and report back here… would really appreciate as much detail on how to do this as possible… thanks… 
Can’t you just run the connection from Unity via websockets or HTTP, and treat HC like an API?
Is this using the holo network?
The easiest path would be to rewrite the chaperone and use Holo Host for mobile apps, yeah. Native Holochain apps, if we can get the conductor to run on mobile devices with good battery performance and acceptability to the app store review process, would just be a local WebSocket connection between the conductor and the Unity front-end. But I suspect there’d be a fair bit of tooling involved to get the current state-of-the-art working natively.
Someone call me out if I’m missing the core ethos of Holochain… but why should native mobile apps be required to care about hosting? Can’t stake in the health of their DNA exist in other machines who are dedicated to hosting the required DNA?
I.e. if I want to deploy a certain app (especially one which consumes loads of processing or storage) just ensure that there is economic incentive produced by the clients (i.e. fees) for other machines to take on the hosting requirements.
If my brain is correct, and bear in mind that I’m just less than one cup of coffee into the day and it’s disgusting instant whilst I await my Dark Arts Coffee (affiliate link, get £5 off, they ship worldwide, it’s awesome stuff) delivery of “Shake Me Lucifer” and “Raise The Dead” (Aeropress grind of course because I’ve given up with manual grinding) which unfortunately I’ve just discovered won’t be arriving for at least six hours, I believe this question was answered by @artbrock recently in a thread about incentives for validation, i.e. yes, you can alter your span of the DHT and the best way is to ship with sensible defaults.
Thanks for that link. Brock’s perspective helpful there.
