Hi everyone,
We just sent out a batch of 500 more invitations for the iOS beta program. Thanks to everyone who is helping us test. Please keep the bug reports coming.
Regards,
Evan
3 Likes
I found some problems on the list,
I turned on the Show Filter Bar
And it didn’t work on iOS (it only worked on Android)
Android:
IOS:
And when I tried to put in such a list Hello, World (with list from csv row
)
I got a weird result (it only happens on iOS):
And the SelectionIndex block doesn’t work properly (only on iOS)
It gives the index that follows (for example, the first index in the list would be considered as 2 instead of 1)
1 Like
@Point
Thanks for the report, but in the future please submit issues using the iOS Beta Testing form as it gives us a centralized way of managing incoming bug reports.
1 Like
I have a question related iOS version as I have not tested it yet.
Will it support extensions ? If yes will we have to write extensions in Java and Swift both ?
3 Likes
That would be too good to be true, but I have little hope ...
1 Like
Our current position on this is that extensions will not be supported in the iOS version of the companion as it likely violates App Store Review Guideline 2.5.2, which prohibits apps from downloading and executing code to change the behavior of the app.
However, once we have the system (companion plus build servers) stabilized we may decide to support extensions in compiled apps, in which case you will need to write a Swift version in addition to the Java version.
6 Likes
I do not think this violates the review guidelines, note that this sentence is also written there:
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.
1 Like
In my interpretation, extensions would violate the clause “Such apps must make the source code provided by the Application completely viewable and editable by the user.” as not all of them are open source nor would they be editable on the device.
3 Likes
Got it, but I think you should still ask apple about it (in my opinion this is an unusual case😅)
1 Like
The challenge is that App Inventor is already balanced on a knife’s blade with respect to Apple App Store approval, and we’ve already had many back-and-forths with them as they review versions coming in. Extensions could be the thing that pushes us firmly into the reject side of things so we need to be extremely careful. As far as I have been able to determine through second hand sources, the iOS dynamic library linker will only link code that has a digital signature trusted by iOS, so it’s also possible that extensions won’t be feasible because the operating system flat out denies the capability, in which case we might need to fall back to JavaScript based extensions (which depending on what you want to do may or may not be useful).
2 Likes
With regard to extensions, the situation is understandable, but are you considering the possibility of creating, along with extensions, a block for adding source code to the project, how does this work in Sketchware using the example of the “add source directly” block? In this case, the code is mounted in the source code and there should be no conflict with Apple.
1 Like
Hi Ewan Patton,
about extensions and IOS what will happen to BLE Extension. Will it not be possible to use it? Why not add BLE to the App Inventor Connectivity menu instead of having an extension?
I think BLE for App Inventor is fundamental
A last question
on the site http://doesappinventorrunonios.com/
I have seen that almost everything is ready except that BluetoothClient and Bluetooth Server is there a particular reason? Are You planning to develop this part too?
Thanks Best Regards
Marco
1 Like
My understanding is that the block was removed back in 2018, but if they've added it back--great! I don't know how they do it, but if I had a guess (based on my experience), you can embed a Java compiler such as the Eclipse Java Compiler (written in Java) into your Android app along with the dx.jar utility (converts JVM bytecode to Android dex bytecode) and then create a DexClassLoader to load up the compiled and dexed source.
To do the same technique on iOS, you'd first have to package a chunk of the Swift and LLVM toolchains (cross-compiled for ARM), and then try to load. When I did my initial research, it sounded like dlopen, the system call to dynamically link libraries on macOS/iOS, does not dynamically link libraries that aren't signed by the same key as the calling app. I haven't tried to verify this by doing it myself, but if it's true that means that if we wanted to support extensions MIT would need to sign the extensions with our key.
4 Likes
We will likely bake it into the iOS version and possibly into the Android one as well. The primary reason at the time for doing BLE as an extension is that not many phones had Bluetooth 4.0 and since we were still learning what was capable it made sense to be able to iterate separately from the rest of App Inventor. Now that things are more stable and most phones have BLE, it would make more sense to keep it as part of the core system.
The BluetoothServer and BluetoothClient components make use of the SPP over RFCOMM Bluetooth, which as far as I can tell CoreBluetooth (Apple's Bluetooth API) does not support. My understanding is that CoreBluetooth only supports GATT, which means it can do BLE but not "classic" Bluetooth. We've done a couple of hacks to make it so that the Ev3 LEGO Mindstorms kits will work though.
2 Likes
Thank you, Evan, for your detailed response!
Hi how can I get beta testing please is it possible , thank you .
Hello I would like to be in the testing program !!! thanks you.
Same here, waiting for response after submitting an application weeks ago
Sorry for the delay in replying, but I think you should think twice about using Javascript-based extensions.
I'm not yet an expert on extensions, but I think the extension based on Javascript will not work fast and high quality compared to an extension written in the native language of the device (Swift) and in addition I also think there will be a lot of things that can not be done with extensions based on Javascript code.
If I understood correctly the problem with using extensions happens because of sending the code to the companion, then maybe we will allow the use of extensions only when the application will be installed on the device (in iOS)?
Yes, that is something that we are considering.
2 Likes