I'm working (helping out) on an iOS app. On most devices the app's stabilized storage use is within 60-80MB. The same app (and same revision) on the iPhone 6+ starts using Gigabytes of data within minutes ... to the point of filling up the storage and I can't even run the app from XCode anymore. I've only been able to get it on the iPhone 6 once, but it's a regular occurrence on the 6+. I've also tried on a range of other devices from 5th gen iPod touch to the iPhone 5 and no other device goes over the 80MB.
The only portion of code that uses a significant amount of storage is the image caching, which caches the (static) images downloaded from the server keyed on the image id. Then again this code is (or seems to be) working fine on other devices. It is also a portion of the codebase that hasn't changed in a while.
Can anyone think of a reason why this issue is only seen on the iPhone6+ (and to a much lower extent the iPhone6)?
This isn't a solution, since it's impossible to know what's happening, but you should look at the following:
Is this reproducible on the simulator? (file system is easier to view)
Does the storage get freed when the app is deleted?
Can you see the data in the device organiser in xcode (they keep moving it, but somewhere you can plug in the device, see the app, and then see the file sandbox for that app)
What data is it? This should give you a clue as to its origin
is there a set of actions in the app that kick off the problem?
If this works, you should get a clue as to the offending code. Then, update your question, unless the solution is obvious!
The problem was that malloc stack logging was enabled and not set to compact. It logged every single allocation made by the app and it was the log file that grew so large.
As to why it only occured on the iPhone6 and iPhone6+, I still don't have an answer.
The problematic file was stack-logs.773.1006c8000.REDACTED.wmQj2k.index. It grew to 700MB almost right after login.
Much thanks to #jrturton because his answer really lead to this.
Related
I created my first app back in July. It came out to be 55mb. I have recently noticed that the Documents and Data section for my app is 150mb, nearly 3 times the app size. Doing more tests I have realized that each time I play the game it increases by 1mb. It is now at 170mb.
I am using Unity 5.6.1p4 and Google Admob.
My app does not download any update files to run the game so that isn't the issue.
I have a couple of guesses but none seem very likely:
1) My game is only about half as optimized as it should be. I still use a lot of instantiate and destroy. An other post said that the memory issue is due to Apple's inability to garbage collect. That is a possibility but I cannot understand why the data from instantiate/destroy would be cached. I also find it hard to believe no one else has had that issue.
2) When the game first starts, it automatically loads a banner ad and a video ad so that there is no delay when the user first requests a reward video. Some people have said that Google Admob caches ads so there is less data usage. That seems like it would cause some increase in file size but 170mb is too much data to be cached. Again I find it hard to believe no one would have complained to Google about this before.
Any help would be greatly appreciated. I cannot figure out what would be causing it. If you are interested in seeing the problem first hand, the App Store link is https://appsto.re/us/nco9gb.i
Ok, here is my findings: This is either an issue for older phones, or iOS 10.x.
However, I do not know which. I am able to test iOS 10 on older phones (5, 5s and ipad 1). I am not able to find any newer device still running iOS 10. This memory glitch does not seem to happen on iOS 11. I was able to test it on 3x iphone 6s, 2x iphone 7 all running iOS 11.It is not as clear as I would like it to be but iOS 11 does not appear to have the memory issue. As much as I would like to find the cause and fix it, I think the majority of people should be safe because they update.
We've developed a Photo Editing extension to edit user's photos. But the photos which user take have large high-resolution. When editing them in extension, it will cost about 100-200MB memory and extension get crashed. But we can't reduce user photo's resolution, how to apply more memory in Photo Editing extension?
I have the same problem. I'm writing an extension to complement my photo editing app. My filter pipeline is relatively complex; it uses a maximum of 6 image-sized textures at a time. However, in the main app I can even process the full camera image size of 8 MP (iPhone 5s) without running into memory issues.
In the extension, I use the display-sized image given by the framework for displaying the preview of the filter to the user, which works perfectly fine. But when I try to apply my filter to the original image as soon as the user taps Done, the extension crashes with the error message Terminated due to Memory Error (in Xcode). I even refactored my shaders and texture management code to only use half (!) of the previous amount of memory, but the extension keeps crashing.
I know Apples guide explicitly mentions lower memory limits:
Memory limits for running app extensions are significantly lower than the memory limits imposed on a foreground app. On both platforms, the system may aggressively terminate extensions because users want to return to their main goal in the host app. Some extensions may have lower memory limits than others: For example, widgets must be especially efficient because users are likely to have several widgets open at the same time. [...]
Keep in mind that the GPU is a shared resource in the system, and so app extensions don’t get top priority. For example, a Today widget that runs a graphics-intensive game may give users a bad experience on both platforms and is likely to be terminated because of memory pressures.
But I don't see how complex photo editing apps are supposed to work with that. The current memory constraints are clearly too high. The only option I see right now is to reduce the image size when saving results and prompt the user about it and tell him/her to use the main app for hi-res export ... which totally misses the point of the extension. I hope Apple will raise the limits before the final release of iOS 8.
UPDATE
I just updated to the iOS 8 GM release and the GM release of Xcode 6. Now everything works perfectly fine! I am able to process 8 MP images without any memory warning now.
While using Xcode 5.1 to deploy our iOS application I am seeing quickly build and say "Running on iPad Name" but it doesn't launch the application for a little over 7 minutes. When I tap on the status bar at the top for more information it says "SandboxingApplication."
This does not happen on other iPads that we use with the same application.
Any ideas? I've tried all the basics like restarting the device, Xcode, and my computer.
You already said it:
This does not happen on other iPads that we use with the same
application.
That's the point, you'll have to reinstall the iPad. Some time ago I had a iPhone 3GS for testing on which it sometimes also took minutes to launch the app. Xcode behaved like what you described, showing "Running on DeviceName".
But although this iPhone is older it hadn't been always this slow. After I restored it from iTunes it again was pretty much faster.
Finally with the help of #flowmachine1 this is solved! It was fixed by:
Deleting Derived Data
Clean Project
Delete App and Reinstall
Thanks so much!
It could be really any issue, but here are some troubleshooting tips.
Restart Xcode and iPad (You already did it)
Try to create a new Project, and try to run it on the iPad Air (Let me know the comments below what happens)
Reinstall Xcode (Most common fix)
Also report to Apple, if none of those fixes work, https://developer.apple.com/bug-reporting/.
Thank you.
I've nailed down one cause, for my situation at least. The app's sandboxed area is huge (gigabytes) as it contains a large amount of resources (as discussed here). Wiping out these resources prevents the delay in the sandboxing process (with the unfortunate side effect of rendering half of the app unusable).
I can only assume that, as part of attaching the debugger, some processing of each file in the sandbox has to occur every time, and it is this process that is taking the time.
The resources are in the application support directory. If anyone knows of a way to mark or relocate these files to improve the speed of the sandboxing process I'd be very interested to hear (and would award the bounty).
Well, I'm running apps on an iPad Air here and it runs in just a few seconds, using Xcode 5.1 and Xcode 6 (beta 4). So, I'd guess three possibilities here:
Your Mac's HDD is failing, or your app is very large (having GiBs of files OR thousands and thousands of small files). You already said your app has 27MB, so size shouldn't be the issue here. Unless you're talking about a 27MB .ipa file, which is compressed. If your IPA contains 27MB, the app itself can be rather big (not enough for 7 minutes sandboxing time, but affects the sandboxing time.)
You're out of RAM memory on your mac, which causes memory swapping. This can easily lead to 7 minutes build time.
Your USB cable (or port) is damaged. I tried using a damaged cable before, and even with the basic templates that Xcode has I would take several minutes to run it on the device.
I'm working on an iOS application which is developed for all devices (retina and non-retina)
The size of the app is too big now to have compromise for all devices. (Why should iphone 3gs suffer size where it does not get quality?)
Now, I would like to know if there is a way to optimize the size of game installed on the device.
Specifically, is there a way in itunes submission process where we can have additional downloadable content on the server and can download it based on the device ?
We can have assets broken based on the devices and still can save some size on each device.
There is no way to do this thru Apple. The app isn't even necessarily downloaded to a device initially, it might be downloaded to iTunes on a computer instead and synced to the device. Also the user might download it on an iPhone, sync it to iTunes, then sync it to an iPad, so the only time it would actually be downloaded is on the iPhone. So if it didn't include the iPad resources, then the iPad would have a problem running it in this scenario.
You could always have content that the app downloads from your server upon installation, which could reduce the size, but would delay the user starting to use the app upon first run. You could also include only retina assets and generate the non-retina assets upon first run by scaling the images to half size and saving them for subsequent use. This would also take a little bit of time, although probably less time than downloading assets.
You could always break the app into iPhone and iPad versions as well, which would reduce the app size. This would also give you the ability to set a different price point for the iPad version. This is very common and can definitely help reduce app size for all users. This would also be the recommended way of handling this. Note that this means you'll have two separate versions (different app IDs) on the store. Typically people append something like "HD" to the end of the iPad version when they do this.
In response to Apple's changes in iOS data storage guidelines I recently reconfigured an iPad app to store its documents (50MB+) in the library/caches folder.
During testing in the iOS simulator I didn't see any problems with this cache when I simulated an update (following Brad Larsson's suggestion). I also tried deleting all of the contents of the library/caches folder to make sure that my app could recover.
However, when I released the app upgrade I found that my users complained of problems that were traced back to the iPad partially deleting this cache. It seemed like sub-folder structure was at least partially left intact, but sub-folder contents were deleted.
I've redesigned the app to deal with this situation during an upgrade, but I'm worried about what will happen when the iPad decides to clear the library/caches.
Does anyone have any experience or insight into the time when the iPad would try and delete items in this cache?
Thanks
There is no 100% clear answer to this question, because Apples iOS Data Storage Guidelines are very vague … They don't explain in which cases iOS 5 will delete data inside the cache dir …
In most cases iOS starts to kill files when it's getting low on disc space, but sometimes my app lost data for no good reason. So I had do implement some kind of recovery modus to redownload/-generate files the app needs.
This article is interesting: http://iphoneincubator.com/blog/data-management/local-file-storage-in-ios-5
The documentation states the following:
On iOS 5.0 and later, the system may delete the Caches directory on
rare occasions when the system is very low on disk space. This will
never occur while an app is running. However, you should be aware that
iTunes restore is not necessarily the only condition under which the
Caches directory can be erased.
The part about it never occuring while the app is running is crucial for our app, and is a really good insurance that we won't get unexpected behaviour.