My colleague (an IBM Distinguished Engineer) and I found something really interesting -- and troubling -- about how FF handles events after navigating away from pages (particularly logged-in page).
Made a project of the test we created (see link in comments) to get to the bottom of it. See below, and reach out if you want the test package. (Will try to publish it to marketplace or push to github, so that others in the community can test for themselves.)
Summary: Particularly for projects that run pageload logic on the page designated as logged-in page, a warning -- flutterflow is rendering the page multiple times, even after navigating away from the page AND even after the user logging out. This means your custom functions/etc are doing unsafe things, which you will observe if you're watching your xcode logs when deploying with localrun to an iphone/etc. We created a test project to illustrate and investigate this bug (or possibly misguided 'undocumented feature'). See below:
RenderBug DoubleTap bug Test: Page1 is set to home and prints log message. Button to Page 2, which does same. Button to Page3, which goes home (and to Page 2). Turn off "allow back navigation" from all pages/buttons, and each message will fire only once. If you turn on back nav, each message will fire multiple times, and the message from Page 1 will print even when you are navigating from Page 3 to 2, and so on. This is not good -- this happens in our production environment, even rendering our home page (which has a lot of business logic in onPageLoad) AFTER the user logs out, tripping security alerts as the logic tries to access data the user no longer has permissions for.
Publishing this so that the community can take a look. FlutterFlow support initially was interested enough to ask to work together on looking into this, but then -- I think -- a different support person must have cycled in, because their messages after we responded with "happy to help" was the boilerplate "we can't help you but we have excellent community resources". Lol
Well, here we are, trying to be the helpful "community resource" that 'support-person#2' decided not to be.
What we did to handle this in lieu of FF looking into this troubling issue was to set our loggedIn page to an inert "loading" page which simply redirects the user to our actual home page (with a button that does same if a user finds themself somehow on that page without the redirect). That eliminates the firing of business logic after logout and other inappropriate spots. Also, we did 'emergency surgery' on the entire app, removing every case of back navigation, replacing them carefully with deterministic navigate-to actions (with 'allow back nav' off) and for good measure turned on "disable android back button". This eliminated the problem and prevented the null and "accessing deactivated...unsafe" errors (which were sometimes causing red-screen-of-death for users).
We think we understand why this is happening, and it's something FF and the community should look into. One mroe thing that prevents what could be a professional tool from being more than just an MVP-assist that outlives its usefulness once a team goes to production with something users need to rely on.
Until this (and the key insecurity issue) is fixed, I wouldn't want to be supporting projects like banking applications on FlutterFlow.