I need to add more png images to my app. When the size of the .cod file crosses 5mb it throws a runtime exception, and I cannot figure why, even with a debugger. If I remove some images I can run the app. I am using BlackBerry OS 4.7 with the storm. Later OS versions also have the same issue.
Hi Arhimed thanks for your
suggestion.How to do lazy resource
loading? When I am taking all the
images before main method I move the
images to SDCard.But it is throwing
same runtimeexception and I cannot
compile it.
Under the "lazy resource loading" I mean you could host your images somewhere in the internet. So on the first app start, being under a splash screen, you would download them to SDCard (or to Device Memory if Device Memory is big enough - it is fully up to you where to store the images). On a slow connection it could take minutes, so you definitely need to inform users about what is going on, so they don't think the app has hung.
Yes, Use OTA in Following command on Application folder.
cd application dir.....
ren appName.cod *.zip // this will divided one cod file to multiple part it.
and now you can extract this zip file on specific folder and also add it's .jad file
Related
We have an app currently in the App Store, and its size is as follows according to iTunes connect:
iPhone 6: Download size 21.8MB, install size 28.5MB
Now this is not too bad. But with a newer version we have uploaded to iTunes connect, the sizes are like this:
iPhone 6: Download size 35.5MB, install size 73.1MB
And the original package compressed size is 114MB.
Now this is too large, even unacceptable. I have checked the .app file within the archive(which is 178MB), and surprisingly discovered that my code alone takes 55MB(which in debug mode is only 11MB), and swift standard libraries around 40MB.
The function of code of this version does not differ much with the previous: we added iPad support, added a few images(the asset is 7.8MB on both debug and release archive, which is not a problem), and updated our project to swift 3.
All the release sizes above are with whole module optimization turned on. Might there ba a configuration in my build settings that may leads to this huge size? If not, what else could I do to reduce the app's size as much as possible?(especially the 50MB codes)
Besides, WHAT is the cause of this? Is it swift 3 since we didn't change our code much?
We also face such kind of issue in our previous app. At that time we make below steps to check which part of application is taking more space.
1) Copy Final IPA file which was generated by Archive.
2) Rename "application.ipa" to "application.zip"
3) Unzip application.zip file.
4) Open unzip folder and find "application.app" file in "Payload" folder.
5) Right click on "application.app" file and select "Show Package Contents".
6) After click on that you will see the list of all the files added in your final application bundle.
From that file listing you can see which file is taking lager space and act accordingly.
Assets.car : it's for image assets added in your application.
Frameworks : all frameworks list which are added by you in your code.
file_name.nib : This file is for your xibs added in your project.
file_name.storyboardc : This file is for your Storyborad added in
your project.
Apart from that their will list of font, images, videos, bundles,
etc. files.
From these step you can get an idea that is the cause of build size.
My iPhone app has recently got a little larger than I'd like (nearing 100MB) and I'm not entirely sure what the cause of it is.
There are many apps for the Mac like DaisyDisk that let you see the make up of your Mac's storage, but is there something where I can see what's taking up so much space in, say, a .ipa file?
Bryan's answer is the way to go. Unzip your IPA (Rename it from .ipa to .zip), find the .app file in the unzipped folder, option click the .app file and view contents, press command J and check "calculate all file sizes", and then sort the results by file size. More than likely you have big media files in your app.
If you try this with iMovie, for example, you'll find the the largest folder in the app is called "Assets", and it's 261 MB.
We are developing an iOS app with Enterprise distribution.
It ran well in hundreds of devices, but we found some iOS 6.1.3 devices failed to launch it hours later the first run, because the App's Documents directory became a file !
Our App did nothing special except it was downloading about 80MB MP4 files from a remote HTTP server.
I assumed that something wrong when it operated the Documents directory, but so far have little clue to identify what's 'dangerous' usage in our codes.
Did you have encountered similar problems? How did you fix it?
Thanks a lot to anybody kindly helping to figure it out.
What I suggest doing is for your app to test for this when it launches, and if there is a file there, move it to some other place (like the temp folder), then create the Documents directory, then move the file back into that directory with the same name (or change the name). That will at least prevent your app from stalling.
If you have any means of remote logging, you could bin hex the first 64 bytes of the file and send it to your service for analysis (if you know what's in the file it should help you figure out who created it.)
Hi guys I have a media heavy app for the iPad and my archive is ~370mb. For what I'm doing, that isn't unreasonable. If i view the xcarchive in finder it is ~391MB, the .ipa is ~388mb, which roughly corresponds to the size of all my assets uncompressed.
So I double-checked the actual usage on my test device and it is 755 megs! This is similar to the "estimated app store" size shown in organizer.
I checked usage on several other test devices and it is the same.
I read the other posts about the organizer estimate tending to be inaccurate, but does that translate to the usage indication on the iPad itself? Shouldn't the iPad just report how much actual space is being used?
370 mb (double) of extra usage can't be anything to do with the executable not compressing, and this shouldn't be a result of PNGs being somehow expanded, I use a ton of jpegs because they are so much smaller.
And the whole compressed/uncompressed discussion feels like a red herring because if I simply get info on the uncompressed assets folder in finder, it is ... 355 mb. So I can't understand how compressing and then uncompressing a bunch of images would double their size.
My only theories are:
- The usage on the development iPad is for some reason no indication of final app size
All my jpegs are somehow being converted to PNGs inside the ipad itself ... ??? really how is that possible??
I have two video files, they could somehow be automatically converted to another format .. ??again, really?? that sounds impossible
the app has in-app purchase capability, it could be somehow allocating disk space in anticipation of future purchases?
I hate all of those theories because none of them make sense. Any of you ever run in to this before?
So write some code in your app that after launch uses nsfilemanager to walk your complete app on the device (or simulator)and tally the totals and log it. This way you will know exactly. Also recall that the file system uses discrete disk blocks of fixed size so 1 byte files actually consume more, but this is probably not your problem.
Also zipping media rarely results in space savings.
This is similar to the "estimated app store" size shown in organizer.
You can check out why by examining the contents of your archive:
Open Organizer, select Archives, select your app, right click on your archive, Show in Finder, right click on the file, Show Package Contents, open Products, open Applications, right click on your app bundle, Show Package Contents.
Also, Xcode might combine retina and non-retina images into a single multipage TIFF file. Check out this answer for more details.
I am developing app for studying foreign languages, and I'll need to ship 80000 little audio files in my app.
To reduce the size of my app I decided to ship only part of them in the bundle, on the zip archive, and then un-archive it to documents directory. Then, when iPhone will be in Wi-Fi network, I'll little by little download all the others.
But the problem is that Apple says, that we are not allowed to store big files in the Documents Directory. Flagging files for not backing up works only since 5.0.1
So I see two ways for me:
Ship all the files without zipping them and storing them in the app bundle – but that's too huge.
Ship a zip, un-archive it to the cache directory and then check, if they are (not deleted by system), and download one, if it's removed.
What should I choose or is there any other way for me to work it out?
Zipping audio files isn't a good way. I'm sure that saved space will not play any role.
Best solution is to use AAC encoded audiofiles.
Choose suitable quality between 64-128 kbps. And probably mono.
iPhones 3Gs and higher have hardware support for this codec.
There isn't much point in zipping files in the app bundle if you will just decompress them to the documents directory. When app bundles are delivered to iOS devices from the app store they are zipped up anyway (.ipa file), so unzipping to documents will make your app actually take up much more space on the user's device (once in the app bundle and once in the documents directory).
Automated way:
If you want to download them without using too much documents space you can write a predictive cache which has a maximum allowed size. You can keep track of when each file was last accessed and when you need to download a new file remove the oldest-accessed files until you have enough space. Your app can predict which files are needed next based on progression through the lessons, but even if they access a not-present file you can download it just-in-time and add it to the cache for future re-use.
Manual way:
You could provide a user interface to show the user how much space the different lessons are using and split it into lesson packs. Allow the user to control which packs remain cached and show how much space they use. They can decide when to download new packs as they progress through the lessons and when to remove old ones (if they want to save space). If the user wants to keep the files locally then you should let them, even though it uses lots of documents space.