Ok, I was just saying I want a way to bypass the app store.Delivering mobile app on hex.pm would be very nice.
derek-zhou
andyleclair
Apple specifically forbids this and any app that attempts it will be rejected. If you care about getting your app on iOS, you simply cannot do this.
0
jam
I don’t think that’s true. There are many Capacitor / Cordova apps (aka apps wrapping a webview) on the App Store. These can be updated without review unless you’re updating a feature that uses an iOS feature.
0
andyleclair
Sure, if you’re wrapping a web-view, but that’s not a native app. The native app review process is much more stringent. I’d think if you have the app running locally on the device (say, a LiveView app) that you could update remotely (specifically NOT loading a remote web app but updating the on-device code) that would be rejected.
1
jam
Mob seems cool. Would it offer any benefit versus writing a native iOS app other than being able to write things in elixir?
I wonder would AtomVM be a better fit? I’ve heard BEAM is a resource hog but maybe it’s fine on iOS, I don’t know.
0
GenericJam
@andyleclair there’s a bit of wiggle room here. If beam code can be defined as ‘interpreted code’ it can be allowed. This is essentially the space codepush has been operating in for years already and I believe LiveView Native apps have already made it through the app store approval process and they use the exact same mechanism.
@Grouvie why not LiveView? This is the approach (similar?) taken by elixir desktop. I don’t want to do it this way. It’s unnecessarily heavy to wrap the server and the client together although it makes sense for their use case. I briefly considered LiveView > LiveViewSvelte > SvelteNative > NativeScript but after making a proof of concept that was just LiveView > NativeScript I realized NativeScript is just referencing the native elements which I could do myself and cut out all the middle layers.
I had a few years with React Native and one of the things that annoyed me about it was all the layers. Something would break in one of the layers and then you have to unexpectedly spend a day fixing it because of a library change or something. So I’m trying to balance simplicity with convention.
@jam benefits of having the BEAM on board are numerous from my perspective.
Event handling suddenly becomes very easy. In general I love the BEAM runtime but for mobile apps it’s a great place to have something like the BEAM that handles errors well. Everything you love about the BEAM runtime is suddenly available inside your app and not on a remote server. Right in your app.
Hot code upgrade. You could get really crazy with it and hardcode your data in the app itself and just send an updated version of beam code every time you want to show something new in the UI. I’m not promoting this but it is possible. Going through the app store is a really annoying and time consuming process. Delivering to the web is a dream come true because there are no gatekeepers apart from the restrictions in the browser. I’ll put in some reasonable security precautions in the app like code signing but this will essentially come down to trusting that no one takes this library and builds something malicious with it and crashes this option for everyone else. So, yes, you could completely change your app after it gets on device but the ecosystem does have some defences against this like you can get reported. You also need to have permissions granted in order to use aspects of the phone for this very reason. It would be suspicious if your flashlight app needs access to the whole file system.
BEAM distribution: you can link nodes directly to each other. You could imagine phone to phone communication, privileged access to your own server via your phone, etc. For example, you could run a game on two phones with one phone being the screen and the other one being the controller.
Whatever you can already do with BEAM distribution you could do here. Obviously you should understand the caveats that BEAM distribution != server <> client. It is privileged access to another node so you should exercise caution.
Whatever else you love about the BEAM is now on your phone: pattern matching, etc.
I looked into AtomVM and it isn’t feature complete and it’s also trying to do things in a different way, etc. I’m very grateful for everything that project is doing but I didn’t think it was the right fit for this project.
I actually thought I was going to have to rewrite a minimalist BEAM to be the BEAM but smaller but after my initial experiments with getting the BEAM started on device I realized it’s already light enough. Using the actual BEAM greatly reduces my maintenance burden and keeps the framework feature complete with the BEAM.
3
derek-zhou
There are many superapp/miniapp combos in Asia. Installing non-native code not through app store is something Apple hates but impossible to get rid off completely.
0
GenericJam
It’s not my intention to distribute through hex.pm. The distribution would be through the developer’s server. Perhaps there will be a business in it for someone to run this code server that signs, etc. but the intention for now is that the developer runs their own server for hot upgrade code.
0
jam
This syntax seems like it might get a bit unwieldy. I wonder if there’s something a bit more elegant.
0
Grouvie
AtomVM won’t work with my approach. AtomVM’s own docs say it targets tiny/lightweight systems, implements only a subset of BEAM/OTP, and is “much slower than BEAM” even with JIT, while using less RAM.
1