Widespread serious problems on iPhone

[Patrick_Paul]

I have 8 apps for different uses that I maintain.  Some are larger, some are smaller in terms of data.  About half of them are very photo capture intensive, the others have zero or very few photos.

I have been getting sporadic reports of problems with users with iPhones.  So, I decided to do a survey, and the results are stark:  Out of my 40+ users, if their platform is Android, they're fine, if they're using iPhone (which accounts for over half of them), they are all experiencing serious issues with crashes to home screen (which often results in data loss), photo uploads (where applicable) and about half of the iPhone users also report extreme heat and battery drain.  This appears to be the case no matter which app they use (large or small, photo-intensive or not).  It all seemed to have started about 4-5 months ago (nobody can pin it down for sure) and does not relate to any changes I've made since it affects all apps across the board.

I had reached out to support previously when an iPhone user contacted me about these problems, and they were absolutely no help.  I granted them access to the apps, all they did was change settings without my knowledge (which only served to cause additional chaos) and offered no actual help or explanation, eventually they just stopped responding.

So.... What's going on with iPhone and Appsheet?  Is there an unresolved bug at the core level?  Did Apple change something in iOS that is causing issues that Appsheet has not adapted for?

[WillowMobileSys]

---

@Patrick_Paul wrote:

This appears to be the case no matter which app they use (large or small, photo-intensive or not).  It all seemed to have started about 4-5 months ago (nobody can pin it down for sure) and does not relate to any changes I've made since it affects all apps across the board.

---

There are many, many users on iPhones in the AppSheet Platform.  There haven't been any other reports that I have seen of other App Creators having issues.  I certainly haven't seen any as co-author on a dozen apps covering hundreds of users.

Considering that, if this was an AppSheet-wide problem, it would likely be well-known after 4-5 months.  So, for now, it would seem that the issues you are facing are limited to your apps.

A few questions for you:

• Have you seen the issues yourself?
• Is there anything in common/shared across all your apps?  Datasource, Scripting, external service calls (outgoing or incoming), datasource, etc?
• Have you looked at the Audit Log files to see if any errors are being reported?  If so, what are they?
• How is your App Performance?  How long are the Sync times?
• Are user on the latest app version?  
• What has been done to try to isolate and identify the issue?

As for extreme heat and battery drain and assuming it is caused by an AppSheet app, the only things that come to mind that might cause this are:

• A constantly running process of some sort.  Endless loops are well detected in AppSheet.  However, it is possible to create cyclic set of events that are complicated enough that they do not get detected.  In general AppSheet apps are extremely lightweight in processing and network communications.  It would be difficult to accidently create an app that performs enough processing to overheat the device and drain the battery.
• A huge amount of image/file data is being loaded onto the devices such as for offline access.

Any details you can provide about your apps, the data structure, processes implemented, etc will greatly help in a collective effort to try to help identify where the problem is occurring. 

[Patrick_Paul]

That's the interesting thing, there's little in common between the apps.  Some are huge monstrosities with 15 tables and lots of data and bots, some are extremely simple.  None share all the same data sets, although a few share some.  All use Google Sheets as data sources, only one sheet has any spreadsheet formulas.  There are no automatic processes or bots used except emailed reports that get sent out based on data changes.  Again, Android phones do not suffer any problems, the only commonality is that all the problems are on iPhone.  I did meet up with an iPhone user and observed all the issues first-hand.  I do have two volunteers with iPhones that have done testing for me since they have reported the same issues as everyone else.  They are updated, caches cleared, all settings on the phone verified, etc.  I created a "copy" of one of the apps to experiment with and test.  It is one of the photo-intensive ones since they seem to be slightly more problematic.  We have noted the following:

-Turning off saving images to gallery stops the frequent random crashes, but a user must take all photos with the camera app and load the photos in manually.  Taking photos within the app crashes the app.

-Similarly, turning off offline mode also stops the random crashes, and seems (limited testing) to allow the user to take photos within the app, but then loading photos from the camera roll causes crashing

-Neither of the above stops phones from getting hot, even if they are idle.

[WillowMobileSys]

No errors in the Audit Log?

How many images are involved?

[KON_TROLL]

Well..... this EXACT problem has been one of our largest pains and issues the last year, and the problem is getting bigger. @Patrick_Paul is describing exactly what we are experiencing.

We have reached out to Appsheet Support numerous tims regarding this, but no help there. It happens only when opening the Photo function - either to take a photo or upload from camera roll. And, yes, only on our bigger apps with much data. But not sync related.

[Patrick_Paul]

No, nothing in the audit log, ever.  These seem to be "local crashes", in other words, it doesn't have anything to do with the sync process, it's the app itself that's encountering an error on the device.  I wouldn't expect Appsheet to log anything because there's no transaction in process when the crash occurs.  In my experience, the audit just logs when there's a sync or transaction issue.

Image slots range from 30+ to 15 or so depending on the app.  Most users don't use all the slots.  It will crash on putting the very first photo in.

[Koichi_Tsuji]

@mandard 

For your eyes.

[mandard]

Hi,

We do see on our end as well that certain large apps are causing memory issues. Sometimes, certain apps have security filters set such that only certain users get a lot of data and this might not be apprarent easily to app creators. There are also differences based on the iOS/iPadOS versions in use. We are working on getting better metrics about these large apps and also looking into any possible improvements we can make.

If you have a repro for a small sized app please reach out via our support channel. Happy to take a look. Thanks.

[KON_TROLL]

Do not hesitate to contact us @mandard . We experience the exact same thing!

[KON_TROLL]

@mandard Here is our support ticket: 1-1125000035042

Feel free to enter this app to see. AFH-1506712. Our account is open for that. We have reached out to support, but no progress there.... They last replied 27th of September saying they sent this to experts....

[KON_TROLL]

So glad someone else is addressing this problem as well. Here is what our users experience:

Approx 10 of our users say this is stopping them 6-10 times every day.

It happens only when adding Photos (opening the camera function (to add either from camera roll or to take a photo)).

Her is a screenshot from my iPhone when I tried yesterday. (the app “shrinks” a bit and a frame around appears. And freezes)

At first we thought this was only on iPhone, but it happens on Android as well, but not so often as on iPhone. Then it does not freeze, but appears as a split screen (that still works).

Looks like a much bigger problem and more frequent for bigger apps and on iPhone.

After freeze: App must be swiped out and restart totally to work.

We first experienced this maybe 2 years ago, but a bigger problem now. Versions og iOS or Appshhet seems not relevant. No errors are logged from this into Appsheet (Audit log or elsewhere).

[mandard]

Thanks for the info. From what i gather, this happens for large apps when
you try to take a photo. We are looking into a new improvement around this.
That said, i wonder if reducing the max photo upload size in the editor
help at all.

[WillowMobileSys]

@Patrick_Paul @KON_TROLL @mandard 

All, do note that there are limits to overall data size in the app on the device side itself - i.e. not related to AppSheet.  I suspect your apps are using up that available app storage size leading to the crashes.

A large set of high quality images as data within the app can reach that limit very easily.  It is important to know how many images and the file size of each that are getting downloaded for a user as part of the app data. 

If possible, then set appropriate Security Filters to limit the number of images downloaded to the device in an effort to prevent app size overflow.

Otherwise, you may need to provide an alternative for users to have access to all of the images - e.g. a cloud based storage area that the app simply links to

Please refer to this article on published data size limits.

Limits on data size 

[Patrick_Paul]

If that were the case, why would it only cause crashes on $1000 iPhones and
not my $70 prepaid Android? I will check into limiting file size for photos.

[WillowMobileSys]

It's how the device operating systems handle app sizes.  I'm sure both iOS and Android have app size limits.  Maybe Android allows larger space for each app  OR maybe each operating systems handles the overflow differently.

To determine if this, reaching app size limit, might even be a possibility, you need to investigate the number of images being downloaded and see what their COMPRESSED size is.  How do you see the compressed size?  Place them in a zip file and get the size of that file.

According the above article, the max size is about 5MB...OR...10MB depending on device.  They don't say what the two numbers represent but maybe that is the difference between iOS and Android allowed app space??  And maybe 5MB is iOS size and 10MB is Android size?  If so, then iOS would see an issue with large apps before Android would.

[KON_TROLL]

Thanks for info. It could be you are on to something. But interesting that @Patrick_Paul says: "Similarly, turning off offline mode also stops the random crashes". We have this feature OFF and still have crashes.

Also he wrote: "Turning off saving images to gallery stops the frequent random crashes". I asume he ment on the device (App settings on iPhone). How could that effect then...?

So you think its the nubers of Images (mainly) going through the Sec filter that causes this? @WillowMobileSys  ?

Thoughts @mandard ?

[KON_TROLL]

Here is a image of the split form Android causeb by the same issue and same app.

It's not really a freeze, but a split (or view is moved to the side). The app continues to work and the photo was added. But one have to swipe out and restart for the app to work properly again. I asume the same issue, but just a different behavior on Android.

[WillowMobileSys]

---

@KON_TROLL wrote:

"Similarly, turning off offline mode also stops the random crashes". We have this feature OFF and still have crashes.

---

If the app is crashing because it is exceeding the app memory/space limit, it can happen at any time and depends on the activity being performed. 

With "Offline" mode ON, the app will download ALL files/images, in the background, to the device in an attempt to prepare for when the app MIGHT go offline.  If that list of files exceeds the app space, then the app will crash during the download.  Turning OFF "Offline" mode prevents this large download process from happening and thus could prevent the crashing.  Files/Images are then only loaded into the app when needed.

While turning OFF the "offline" mode prevents the large download of files to the device all at once, it doesn't prevent download of those files if they are surfaced in a view - such a Gallery view of thousands of images.  Or maybe Table or Deck views with thousands of rows that have images displayed.

The common denominator appears to be that the apps use a large number of images.  Images use a LOT of storage space (especially high-quality images) and can exceed storage limits quickly.

I would test your app by temporarily inserting a Security Filter that limits the data downloaded to the device and try using the app with the limited data.  If no crashing then you know it is the amount of data causing the issue.  If the app still crashes then more investigation is needed.

[WillowMobileSys]

@Patrick_Paul @KON_TROLL @mandard 

I'm curious ...any progress on identifying the issue with app crashes?

[KON_TROLL]

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...)

[Patrick_Paul]

I have been on vacation so I haven't had an opportunity to do a detailed debrief, but basically what I did was create a "copy" of one of the worst offending apps and turn off offline mode as an experiment.  It seems to have cured the problem on iOS.  Also, it seems like turning off "save to gallery" has a similar effect on iOS.  We'll need to do further experimentation (and I want to try turning these features back on but limit photo size) to determine if any of them are an actual acceptable fix.

My best armchair theory is that there's a problem with read/write permissions or caching of some sort on iOS.

[WillowMobileSys]

---

@Patrick_Paul wrote:

and I want to try turning these features back on but limit photo size

---

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?"

[KON_TROLL]

@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....

[WillowMobileSys]

---

@KON_TROLL wrote:

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?

---

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:

1)  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.

2)  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. 

[MayhemRitual]

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!

[KON_TROLL]

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.  

[WillowMobileSys]

@KON_TROLL @Patrick_Paul 

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.

---

@KON_TROLL wrote:

After sales of Appsheet to Google the support is just no-existing.

---

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.

[KON_TROLL]

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. 

[WillowMobileSys]

---

@KON_TROLL wrote:

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.

---

@KON_TROLL wrote:

We might try turning off the "offline" mode to see if this solves it. (to bad, though, since field workers actually need that...)

---

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.

[KON_TROLL]

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)

[mandard]

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?

[KON_TROLL]

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.

 

[Adam-google]

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:

1. Crashing intermittently when offline caching is enabled (app completely closing)
2. Device getting very hot and rapidly draining battery
3. Freezing at the point of starting to take a photo (requiring to manually kill and restart the app)
4. App UI getting shifted partially offscreen after taking a photo

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.

[Patrick_Paul · Accepted solution]

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.

[WillowMobileSys]

---

@Patrick_Paul wrote:

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.

[KON_TROLL]

@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)

[CaptainEon]

Although Google may not like Apple, it's about time they took bug reports on iOS seriously.

@mandard 

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.

[CaptainEon]

This isn't a solution is a stop gap measure.

When are Google going to fix this issue?

[Koichi_Tsuji]

Only god knows sadly….

[mandard]

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.