I think this is a critical analysis to the issue.
As suggested above, I would recommend determining the compressed size of all images available to the app. It’s as simple as creating a Zip file of the images to get an indication of the overall size.
Interestingly, I was just re-reading the documentation because 5MB or 10MB doesn’t allow for many images - even in compressed form. I saw this comment:
So, I am back to the question…“What is the size limitation for these external data?”
No, not so far. We have a supprt ticket as well, but no reply. we use 600x600 size on images, but it is still a issue. We might try turning off the “offline” mode to see if this solves it. (to bad, though, since field workers actually need that…)
I feel your pain. Dealing with those iPhone issues must be a headache. It could be related to Apple’s iOS updates, which can sometimes mess with app compatibility. You might want to check out Apple’s developer support or this site (https://multitechverse.com/) for advice. Hang in there, and hopefully, you’ll find a fix soon!
Thanks, but in this case thats not it. This has been a problem for more than a year… Through many iOS versions , Android versions and Appsheet versions. Sent many tickets to Appsheet, but they do nothing about it… We might have to skip Appsheet totally if the Photo documentation doesen’t work properly.
After sales of Appsheet to Google the support is just no-existing. All the BETA solutions from 4 years back is still BETA (charts, INPUT(), Okta, Quick-edit, ++++). I feel the focus for making quality and taking the customers seriously is just missing totally. Sad to see… And Appsheet is not to be found on any top 10 list of no-code or low-code App tools or App builders any more. No wonder… Really a big problem for us, since we have invested so much money and time in this tool.
You still haven’t provided an assessment of the amount of storage space your app is utilizing with all of your images. It is unreasonable to assume that you can throw any arbitrary number of images into a mobile, distributed app and expect it to be able to handle the volume.
NOTE: Storing used images in the app IS NOT THE SAME as images stored in the camera roll.
I honestly don’t know, without your assessment, if space is the issue but it seems like the likely culprit. Help yourself - Assess the storage size all your images are requiring and then investigate if that size could be overflowing the allowed storage space of the app. If so, then you will need to find a way to limit the number of images downloaded to the users.
I don’t know why people keep saying this. I submit to AppSheet support, on average, several items a month. I have, for the past year or so, received replies by the following day and then follow-ups or results at some reasonable time afterwards. I have seen, generally speaking, great overall improvements. I will say that I have seen more of a transition to the two-tier support model recently which delays the final result a bit.
Thanks for your reply. You could be on to something regarding memory, but it is not just that simple. We see this also happens with users not having a large amount of photos. And somtimes after opening the app, it happens after 1 ot 2 adds. We use Default image size (600x600) and do not store content offline. Regarding support, I’m gled to hear your good experience. I just hope that will happen to us as well. We have no feedback or open questions on this from support for the last 3 week now.
Check the “Junk” email folders to be sure their responses haven’t just been missed.
This implies that you did at one time have the app set for Offline mode. I have no idea what happens to all the content if you later switch it off. Does it stay on the device?
One other thing that I just assumed was known but maybe not… you can check the app data storage usage on an iPhone under General->iPhone Storage. Below is an example screenshot. It shows the total space available as well as lists each app and the space they are using. for me AppSheet is WAY down on the list with 142.1 MB. NOTE: all AppSheet apps on the device are listed together under the AppSheet container.
Hello,
Firstly, please do note that we are actively looking into your reported issue. For some customers, the issue vanished after decreasing the total data (number of rows, tables) a given user downloads (sometimes security filters may lead to only certain users downloading a lot of data). That, combined with reducing the photo upload size (if you upload a lot of images seems to work for some customers. That said, as I mentioned before, we are looking into l improvements from our side. @KON_TROLL you mentioned seeing this issue on Android as well..are you seeing photo upload issues? Can you expand?
Thanks a lot for your reply. Very glad to hear this issue is still alive @mandard
Yes for Android the cause is the same: When pressing the camera button in the app, usually after adding a couple of photos first, the app returns in a split screen. But for Android it does not freeze. You can stull continue to use the app (but you only see half of the screen). Here is another example.
Thanks for tip! Apreaciated! Yes we did a check of memory capacity on the device for 6-7 different users. And we also checked if they had a lot of other apps open when this happens. But no pattern there. Several users had few apps open and a lot of memory availeble. The only pattern we see is that it seems to happen after first adding a few photos. (Not the first time after opening the app)
@WillowMobileSys Does this mean that if one check for “Store content for offline use” it does not use the device menory in the same way, and that it could help? (The only problem is that then it downloads a lot of images and use a lot of mobile-data… We tried some years back and got a lot of complains…
No. With that setting on, I think it would make things worse. With the setting on, the app would attempt to download ALL app content, used or not. If the app is already experiencing reaching app run capacity and crashing, the attempt to download even more content would make the errors happen sooner.
To clarify, there are 2 capacities I think we are referring to here:
The static storage capacity - that is what you see as available capacity for storage of the app and its content on the device - running or not.
Allotted run-time space for the app - my understanding is that each app is allowed a max amount app run space in the device RAM/runtime memory.
It is with #2 I think you are having issues. I think the app is trying to load in all of those images using up the allotted RAM space causing a crash. We don’t have any control over how this occurs EXCEPT to limit the size of the space needed by the app. Since your app seems to be image heavy, it is my strong suspicion that the number of images being brought in by the app are causing the problem.
I would recommend finding a way to limit the number of images brought into the app for a particular user at any given time.
Thanks everyone for the details and screenshots and for experimenting with turning off different features. We believe we have found the root cause of a crash associated with the “offline content caching” behavior, which accounts for the majority of iOS crashes in our logs. It sounds like this is the same crash you’ve been seeing. A fix for this will be coming in the next iOS update.
I should mention that it sounds like at least four different issues have been raised in this thread:
The fix I mentioned above should address #1, but this crash doesn’t appear to be related to any of the other issues. We are still investigating #2-4.
Sorry for my absence on this thread after starting it. I have a lot of projects on my plate. So, after extensive testing, I can sort of corroborate what @Adam-google posted above. On iOS, when offline mode is on, all four items he lists above occur. If I turn off the app saving photos to the camera roll, it alleviates item 3, and slightly alleviates item 1, but nothing for 2 and 4. When I turn off offline mode, it fixes all 4 items above. Clearly the issue has something to do with device storage access on iOS.
As a stop-gap measure until Appsheet can correct this, I will be deploying an altered version of my apps that do not use offline mode in order to resolve the issue. I have had two users field-testing this, and have found no drawbacks in our use case. I just find it disappointing that I basically had to do my own support, and that an actual fix doesn’t seem forthcoming soon.
As a well experienced developer, I feel it is worth mentioning that not all defects are created equal. Some are extremely difficult to isolate and resolve. Mostly this is because others, namely support, cannot easily replicate the same issue. Support can only advise based on the knowledge they have.
When it comes to fixing such an issue, it must be repeatable so AppSheet developers can pinpoint where the actual defect is and what precisely needs to change to resolve it. If they can’t consistently repeat it then they have no idea where to look in the code to address it - or even if it is the code! Developers can only fix code they KNOW is broken
For these difficult bugs, it can take a long while to identify and fix them!
One last thing, as App Creators, the owness is really on us to be able to provide to support an example of our issue in as simplified form as possible so that support can reliably reproduce the issue. Easier said than done, I know. Until AppSheet can acknowledge the issue, it our responsibility to continue supporting the issue to our users and searching for a likely root-cause. It is the best way to help ourselves with these difficult issues.
Hi, we have a new iOS version v15.8 available in the app store (you will need to go to the app store and click ‘update’ to get the version). that addresses some issues around crashes when offline caching (would occur when there is a very large list of URLs to cache) and sometimes when trying to upload a photo. Please let us know how this fix works for you.
@WillowMobileSys Partly true, but listen:
We contacted support 1 year ago, and last time 1 month ago related to this issue. No reply or update other than, “still working on this”. They have access to our app all the time, and can easy replecate the issue if they open the app from an iPhone and try. The #3 issue will occur after a few tries for everey user, based on settings mentioned by @Patrick_Paul . So I fear this is just not on priority list for AppSheet. But we have some 800 users now wondering if they must change system for regestering deviations. Huge business loss if so…
@Adam-google Can you confirm you are still working on #2-4? (#3 being the main issue here)
Although Google may not like Apple, it’s about time they took bug reports on iOS seriously.
Fact 1: Apps works fine in Browsers (Safari & Chrome) on iOS and are much faster than with the ‘AppSheet shell’
Fact 2: Apps works fine on Android and Desktop browsers.
Fact 3: Apps crash and burn when accessed on iOS within the ‘AppSheet shell’
IT DOESN’T NEED EINSTEIN to work out the TWO possible causes. And its not us users, or our app design, or settings or whatever the Appsheet developers choose to pass us off with.
“Switch it off and on again just doesn’t cut the mustard!”
I have some major Enterprise projects this year to complete involving 100’s of users and a now forced looking at other low code tools now as a result of my testing on iOS.
AppSheet and IOS just does not work.
This isn’t a solution is a stop gap measure.
When are Google going to fix this issue?
Only god knows sadly….
