How will App Inventor handle extensions on iOS? There's no way existing android extensions will work, and the companion can't have extensions due to Apple restrictions on loading binaries. What is the plan?
2 Likes
Note: This is just a speculation
Possibly, iOS version may have a different extension mechanism. Extensions could have two variants - one for Android as usual (written in Java using Android APIs) and the other one for iOS (written directly in Scheme/YAIL probably [not sure about access to iOS APIs but it could interoperate with native APIs via the interpreter]).
When you connect the companion to the builder, the companion would execute only the variant which it supports.
PS: There could be another variant for the builder itself, which would show the preview of the visible component. This mechanism would help me to achieve my GSoC proposal more realistically.
@ewpatton, tagging you, hoping that you read this. How's the idea? Is it close enough to what you have planned?
4 Likes
Here is the more official answer to this:
It is also important to note that iOS extensions will only be activated after installation on the device (meaning that the extensions will not be able to work through the companion) as Apple's policy does not allow this to be done.
2 Likes
Quoting from here:
Apple started officially allowing programming language interpreters in the iOS App store late Q3 of 2010 (they changed their SDK agreement to clarify this). However interpreters (except for Javascript in a UIWebview) are not allowed to run any downloaded code. Only code built into the app, or typed in by the user.
This would have meant that the companion couldn't download the YAIL code generated by the builder. But, apparently, this isn't the case. So, likely, extensions could be supported as I described above.
Edit:
Educational apps are allowed to execute downloaded code.
2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the Application completely viewable and editable by the user.
It is completely impossible to download and run binaries on iOS. YAIL probably works as an interpreted IR for the companion.
You failed to emphasize an important part of the guideline text, namely:
I expect that Apple would argue that extensions as binary code are not viewable and editable by the user. While I haven't tested this myself to verify, my understanding is that the dynamic library functions in iOS won't load code not signed with the same certificate as the main binary, so even if this were an option MIT may have to sign all extension binaries with our certificate for them to work, which puts us on the critical path.
4 Likes