I have detected and reported the same switch-navigation garbage screen. See Problems with Screen Navigation testing IPAs
After a few screens navigation the app stops.
As I said, there is a solution for my simple test app. But this solution doesn't seem to solve all switching problems with more complex apps.
As my test app shows, every switch between Screen2 and 3 is also counted on Screen1. Of course, this doesn't happen on Android.
In my tests with real AIA when I'm in Screen2 without doing nothing after 20 or 40 seconds the app close itself. It seems your suspect over the iOS garbage collector can be right because my app close itself without any hand operation on Screen2 visible.
Yes, I noticed that in various of my apps too. That's why I first tried a simple app that doesn't have this problem. To find the cause, you must gradually remove all components until the problem no longer occurs. This is very long and tedious, but without knowing the cause, I don't see any other way.
And that's why I said that the first thing that needs to be clarified is how exactly switching works under AppInventor for iOS.
A very simple test with real AIAs. We open Screen1 with Timer and Location sensors. Then we open a Screen2 previously disabling the Timer and the GPS of Screen1. No operation is performed on Screen2. After a few seconds the App closes by itself. It is as if an iOS process deleted or stoped the App since without performing any operation, it closes by itself. The iOS operative system close the app in this case when we have the Screen1 on the second position or undergrund.
May be iOS has a special process to close the Apps in undergrund position that we don't know the selection algorithm.
Post this aia.
I'm sorry @Anke. The real AIA has sensible data about web access and others.
But with examples happens the same (we only need wait more seconds to stop the app)
What about posting this simple example aia...
Thanks. I will run some tests on this and see what I can learn.
Unfortunately, I couldn't learn anything except what I already knew, namely that you shouldn't open any screen (especially not Screen1) twice. I have modified the app (blocks) so that switching the screens should now work properly.
But as I said, switching between Screen2 and 3 always goes through Screen1 first.
testNavigation_iOS2a.aia (17.1 KB)
So my question again:
How does switching screens work correctly in AppInventor for iOS? In other words, does navigation basically have to be done via Screen1?
@ewpatton
Again, it depends on what you are trying to accomplish, and I think the answer is that what you want to do you just cannot do with how screen switching is implemented in iOS. In iOS we have a UINavigationController at the root of the view hierarchy and its first item in its stack is Screen1. If you open Screen2, it is pushed onto the nav stack. If you want to do what your test app does which is both close and open a screen simultaneously, this results in a pop operation on the UINavigationController which goes back to Screen1 and then a push to open Screen3. On Android, the framework doesn't seem to bother drawing Screen1 when an activity is finished but an intent is pending to open a new screen but that's not the case with the iOS code.
In order for this to work, I will have to add some code to the navigation logic to detect when this sequence of events is triggered and then swap the behavior out for something more like what Android does (although what iOS does is technically correct based on the code you've written--it closes the screen then opens the new one).
1 Like
I think I have coded something that mimics this behavior. I will need to figure out how best to deploy a parallel build infrastructure for you to test it.
1 Like
So in testing I was able to confirm also that the issue with the bad irritant messages when screen switching comes down to the garbage collector erroneously cleaning up some references to the other screens in the stack. I applied some code in an attempt to mitigate it but it still happens. I need to dive into that code and figure out why objects that should be marked as alive are not.
1 Like
Thank you for the detailed explanations.
So if switching between Screen2 and 3 necessarily takes place first via Screen1, then that's just how it is. Then I have to adapt the navigation of my app(s) accordingly. All non-Screen1 screens should then generally be navigated (only) via Screen1.
Every non-Screen1 screen can then only be exited using the Back button (< / top left), which leads back to Screen1. I haven't noticed any problems with this way of navigation yet.
I've just posted an update to the build server thread. I think I have come up with a way to make the screen switching work similar to how it does on Android. Please take a look.
1 Like
WOW, great! 
Works perfectly on an iPhone 15 Pro Max (iOS 17.4.1).
1 Like
Hello,
I have tested the new builder version and the Screens Navigation runs well with my real and big AIA. Now I have not the irritant error when switch from Screen2 to Screen1.
Congratulations for a good work.
1 Like