I would hazard a guess and say no as it might not need to.
I was reading this article MIT App Inventor for iOS on the App Store which states that in the very initial tinkering the "first proof of concept .. started as a simple Scheme interpreter performing math operations by running them on (an) iPhone via HTTP and cURL" and i was wondering if that ever made it into the final design?
Additionally, as a side note, is the iOS companion also running Kawa scheme (like Android) or is it another dialect? (or is something else magical happening?)
Probably obscure questions but I ask as I am trying to determine a way to upload files via webRTC to the iOS companion and have them stored on the device. I am able to do this with the Android companion as it has a slightly richer component set to play with and as its code is available soI can see the internals, unlike the iOS internals which are currently a proverbial black box.
The web server concept is used in Legacy mode (which is also true of the Android version). The flow has changed somewhat because of security changes in Chromium and related browsers, but the essence is still there. In the early prototypes I hadn't bothered implementing the HMAC security checks that we do in production but in the version in the store those are in place to prevent malicious actors from injecting arbitrary code into the companion. However, most of our users use the companion in WebRTC mode these days which negotiates its own encrypted channel so the web server is unnecessary in that case.
We use a different Scheme interpreter called Picrin for the iOS version, which is written in C99, and is modified by us to support FFI calls to Objective-C and Swift. The components are written in Swift. No magic here, just a lot of code.
I believe this should still work for iOS. I think we start the web server either way once the 6 character code is processed, but I'll have to double check the code. Like Android you would just have to PUT the file to the server running on port 8001.
1 Like