Trouble with ipa size after changing assets

@Neil Enns -

1) We do have embedded videos in our app. 7 videos which total approx 130Mb.

If these videos are embedded for both portrait and landscape orientations is DPS going to duplicate those assets for some reason??

2) We are not using ANY web overlays.

3) The default folio format is "PDF" which is what we have been using all along. Never changed this setting.

So knowing that we are using the correct folio format is there anything else that could possibly be causing a 30% increase in file size??

Part of the selling point of DPS is that it "supposedly" creates apps that will work in either orientation... many users prefer to read or browse in a portrait orientation... this is a perfectly logical use case and something that your application is supposed to support.

Yet instead of trying to offer any real solution or any information that might actually help me solve this issue you simply ask me why we are producing a dual-orientation folio?? Really starting to wonder if I am getting trolled here...

So from your answer above it sounds as if DPS is smart enough to recognize shared video assets between portrait and landscape orientations... is this also true for images / type?? I am still trying to understand why doing an app in both orientations that uses all the same assets "will almost double your folio size" (your words not mine)

Is there ANYTHING that we can do (short of ditching one orientation) to help reduce the file size of our application (while keeping the dual orientation)?

Ok... so here is some additional info...

Just as a test we produced a version of the app that is a single orientation folio. This version of the app came out at 540Mb (rendered IPA file).

How is it that this version of the app could come out at essentially the same file size as our previous build (596Mb and dual orientation)??

It seems like there is no real consistency to the file size of the IPA files produced?

We haven't changed any content or folio settings or anything like that except for dropping our portrait orientation version of the app.

Thanks very much Neil. Much appreciated.

I am unfortunately out of the office for the night, so I can't get access to the files or DPS, but I will share the folio first thing in the AM.

In the meantime though my team and I started doing some testing, as we were really concerned that the imagery in our app was what was causing the issues.

As I mentioned earlier, we had swapped much of the imagery in our app for .jpgs that are rendered at the correct pixel dimensions they appear at in the app.

We tried quickly swapping out a few of the higher res, and larger file size images for these smaller, compressed .jpgs After running the folio through DPS it seemed to impact file size very little (only dropped the file size a couple of hundred kb) - I am guessing this is due to what you were saying about DPS automatically resizing most images to 108ppi etc.

Dropping to a single orientation definitely had a major impact on the file size. (822Mb for dual vs. 540Mb for single)

Unfortunately the dual orientation is something we have been locked in to by our client.

for this particular app the client is very picky about the image quality and they have made it a requirement that the app support retina display.

Our initial tests running a 1024x768 file and upscaling on the newer iPad didn't have the best results, as the image compression and upscaling left our pixel imagery looking less than optimal.

I finally managed to find this: http://blogs.adobe.com/digitalpublishing/files/2012/03/DPS_iPad3_bestpractice.pdf

This PDF has a  section on file size, and describes using a 1024x768 with images at 144ppi folio for both retina and non-retina display

Would starting with a 1024x768 file and then building a retina folio with those files drop our file size?? or would DPS scale the images up for retina and then result in a similar file size?

@Neil Enns / @Bob Levine

Thank you both for the detailed responses.

We did another quick test working as you described (1024x768 file / 2048 folio). We reviewed this with the design team for image quality (they are super picky!) and we made the call that this will be acceptable for image quality.

I do have a couple of final questions though.

By dropping our indesign file dimensions to 1024, and putting it in a 2048 folio, will this affect the file size at all?

@Neil Enns - you described how DPS resizes every image to 108ppi and the exact pixel dimensions they are shown on screen. If this is true, I am a little unsure of how this would drop the overall file size post DPS render of the .ipa file?

You describe how a 1024 folio will work on both retina AND non-retina displays, this seems to counter a lot of my initial reading on DPS. Are you saying that we can render a single 2048 folio and that will still work on non-retina displays? Or do we simply use the 1024 files to render a 1024 and 2048 folios? Could you clarify that part of the process?

I do apologize for all the questions, but I just want to make sure that we will definitely see a decrease in file size before we take the time to downsize all of our files.

Thanks again, I will report back on file size etc. post downsize.

@Neil Enns - Sorry could you describe that process in a bit more detail please.

We are able to add our 2048x1536 files to a 1024 folio no problem... but this doesn't seem to affect the source files at all.

What I am understanding from both your and @Bob Levine's previous posts is that we must start with a 1024x768 file and then add that to a 2048x1536 folio for retina support.

Can you please confirm that?

@Neil Enns -

Thanks very much... all clear on what we should do now.

We proceeded to do some experiments in terms of file size versus image quality and there is a definite and significant drop in the quality of some type when viewing the 1024 folio on a retina device. Any type that is in an overlay is significantly pixelated and at some smaller sizes borders on unreadable.

Why is it that type in overlays is rendered differently than type simply sitting on the artboard?

Is there anything we can do to change this? a setting or a different way of handling things?

Just wanted to publicly report on the file size drop, as I sort of left it out of my last comment.

As @Neil Enns describes abover, producing a 1024 folio resulted in a huge drop in file size (both of these folios have dual orientation).

1024 folio = 316Mb

2048 folio = 822.5Mb

@Neil Enns - Thank you so much! that is super helpful to know, as I think that is the final key to getting this issue licked.

Thanks again for putting up with me and all of your responses.

It would be great if a lot of these details were presented up front somewhere in the DPS documentation, as I did a ton of reading and watched all of both the adobe and lynda.com video tutorials on DPS and this was not the recommended way of producing folios for retina display.

To be honest almost all of the documentation for DPS could use a serious update, as most of the processes, screens and interfaces have changed with this newest version of DPS.