What are the limitations of the iOS version?

Hello everyone!
On Android it is not possible (at least for now) to create background tasks, widgets, etc ...
I was wondering what are the limitations of iOS apps?
I know it will take some more time before we can compile our apps for iOS, so please note that my question is not for the limitations of the companion but for the built apps.

1 Like

I think this is still something that is open to discussion. The current build infrastructure we are testing doesn't yet support providing the necessary Info.plist keys needed to certain dangerous permissions (location services, e.g.), but that's relatively high on the priority list right now. We also are trying to figure out the best way to support extensions in built apps to allow some adaptability by the community for features we know we won't provide (e.g., in-app purchases). Other than that, I think most of the standard iOS restrictions apply. Apps cannot run in the background except for some limited use cases (location services for navigation apps, Bluetooth, etc.) that are defined by Apple. If there's something in particular that you're interested in I can try to address it directly.

1 Like

I'm sure you're doing your best to find the best construction infrastructure for App Inventor, and I agree that extensions are a much more necessary thing than location services etc ...
But still, will it be supported in the future?
I'm sure it will be a pretty painful thing for a lot of users in the future.

And what about widgets?
Of course this is not necessary now, and it may require a slightly different workspace. But will it be possible to build widgets for iOS?

1 Like

This isn't something we're exploring at this time. If we were to do it, I think we'd want to try and figure out how we could support it for both Android and iOS.

2 Likes

What about the Swift version?
If I'm not mistaken, in the Android version of AI2 it is not possible to use extensions in a newer version than Java version 1.7

We currently compile with Swift 5.

1 Like

Excellent! Will it be possible to update components and extensions to a newer version when it becomes available?

I'm not sure this is possible. When the app is built, all of the libraries are flattened into a single directory, and for stability's sake we'd probably want the version App Inventor is compiled against. However, that being said, Apple and Xcode are much more aggressive about compiling against newer versions of the SDKs than Google is, so we tend to update the Swift version more readily.

1 Like

Here, Apple has a big plus.

1 Like

Yes and no. Previously, Google didn't require us to update the targetSdkVersion, which allowed us to spend less time updating the system to reflect their more restrictive measures. The change for SDK 26 a few years ago killed this approach. Now, we have to adapt to their constraints as they change them while trying to maintain similar backwards compatibility. In Apple's case, while they do require us to update every year to link against the latest iOS SDK, there tend to be fewer breaking changes which turns into less of a headache. From my perspective, Apple seems to be taking a more restrictive stance whereas Google took a more open stance (preferable in my opinion) and is now backtracking more toward what Apple does, which penalizes users generally and App Inventor users specifically who have done nothing nefarious. Therefore, it's a "big plus" given that you started from a more restrictive approach to a (slightly) more open approach versus starting from an open design to a more restrictive design.

Kahneman and Tversky through their experimentation have shown that people typically experience the pain of loss 3x the pleasure of gain, so Apple's approach (gaining some freedom) seems to me to win out over Google's (losing some freedom) even if the end result is the same. This is speculation of course on my part and I haven't done any formal analysis.

1 Like

This thread is 6 months old but as of October 2023, I have an app that works well on Android, using TinyDB and Email intent but while the app loads and the screen/keyboard functions seem to work under iOS, TinyDB and Email intent don't seem to work on iOS. I have not spent much time poking to see what possibly could be wrong, there is no error message or anything, it just ignores the code totally.
Is there an app note or forum post somewhere that may explain how to get those working under iOS?

Eventually, I would like to use TinyWebDB as well, if I can get through the current hurdle.

We only have limited support for the activity starter on iOS, which is how I assume you're trying to launch the email app. If you show the specific configuration you're using to accomplish this we may be able to add support in the iOS version.

Both TinyDB and TinyWebDB should be working on iOS.

1 Like

TestDBandEmail.aia (3.6 KB)

Thank you for the offer!

Here is a simple demo of what I would like the email intent to do. This works under Android but not (of course) under iOS. I also incorporated a simple TinyDB load and save and switching to Screen2 because these functions appear to not work in my actual app under iOS (they work under Android), but they work in this demo, so there must be a problem with my app. I will work on that part :slight_smile:

See also here:

Try this:

Screen2:
grafik