We have released MIT App Inventor for iOS version 0.9.9 to Apple TestFlight. If you've enabled notifications for TestFlight, you may have already received a notice of this update. This release contains the following changes:
Implement SendMessageDirect and MakePhoneCallDirect
Implement missing features of the Screen component
Implement the Close Project menu
Add missing Changed event to CheckBox
Make boolean values compatible across the YAIL-ObjC bridge
Previously, true became #t and false became #f
Fix a crash when checkbox is enabled in the designer
Implement the ApiKey property for YandexTranslate
Add onboarding screens
Fix a bug where the Player.Completed event would not fire
Implement functionality to unregister disabled event blocks
Clean up some internal logic
Fix an issue where LineString could be initialized without any points
Improved memory management logic
Fix a potential stack overflow error
Fix an issue where integers were not behaving as expected
Add some dark mode support for iOS
Address memory consumption issues with the Map component
Fix bug where valid events were unregistered
Add bundled projects
Add Clickable property and Click event to Image
Implement GotFocus and LostFocus events for TextBox, PasswordTextBox, and EmailPicker
As always, we greatly appreciate those of you who are helping us test this release. Please report any issues via the App Inventor for iOS Beta Bug Report form. Please be aware that due to the memory management changes, this release may be less stable than previous releases.
Known issues reported in this release:
Web component's JsonTextDecodeWithDictionaries and XMLTextDecodeUsingDictionaries are not yet implemented
Introduction screens have visual glitches on some hardware/software combinations
Implicit coercion between list-of-lists and dictionaries does not appear to work
Dictionaries render as #<yail-dict ...>
Setting the elements of a Spinner component crashes the companion
Cheers,
Evan W. Patton, Ph.D.
Lead Software Engineer, MIT App Inventor
On behalf of the MIT App Inventor Team
At a high level, there were issues in the code base that resulted in circular references that prevented objects from being cleaned up (aka a memory leak). Over time, these objects would accumulate in memory until eventually the app would be closed due to the system not having enough memory.
More Details
Objective-C and Swift use a memory management technique called automated reference counting (ARC). Internally, objects have a counter so that as variables point to those objects the counter goes up. As objects stop being referenced by variables the counter goes down. When it reaches 0, the object is cleaned from memory. However, you can get into a situation where A references B reference C references A, so the counters will never reach 0. We went through the code base breaking a number of these potential cycles.
Another area that was affected is the bridge from YAIL (App Inventor's internal language) and Objective-C/Swift. YAIL is a dialect of Scheme, and so we have a Scheme interpreter embedded in the code for evaluating the YAIL. The Scheme interpreter uses a mark-and-sweep garbage collector (GC). The logic to interface this GC to how ARC works to ensure that only one reference ever existed per object crossing that boundary was cleaned up, otherwise it was possible that an object could get referenced in your YAIL code that could never then be cleaned up. There was a thornier issue that would sometimes happen where an object would get cleaned up on the Swift side of things invalidating the reference in Scheme, causing the app to crash.
That was "Make boolean values compatible across the YAIL-ObjC bridge". I've updated with a clarification above. Previously, the code I wrote to pass values from YAIL to Objective-C/Swift coerced booleans to the string representations of their Scheme tokens (#t and #f), rather than true and false, when passing them to a function that expected a string. Now it passes the human-readable name in alignment with what the Android code does.
That remains to be seen. Although I should point out that when we go live in the App Store, the iOS companion version will match the Android version. When we build I actually make two builds, one in the 0.9 series (since it has been approved for beta testing) and one in the 2.60 series (which is submitted to Apple for review).
