First App rejected for odd reasons

[Thomas McGrath III]

I hope that didn't sound argumentative. I think this topic needs more discussion and input.

Thanks again Mark for the input on this.

Tom

-- Tom McGrath III
http://lazyriver.on-rev.com
mcgrath3 at mac.com

On Jun 5, 2013, at 8:41 AM, Thomas McGrath III <mcgrath3 at mac.com> wrote:

> Mark,
> 
> At first I wanted to object to the need for JPEG only for large images as all of the research that I have done (especially concerning transparency issues) has told me to never use JPEG (except for the web) in most of my apps but then I realized that I have not tested those same results for iOS and Android engines, so I will need to do those tests again to verify/reject my findings. That said, using 2048 png's with transparency layers on fourteen cards with special visual effects and playing song files on one channel and a voice over on another channel did not slow down either the logic code or the effects code. I created a Ken Burns effect in LC and it runs as smoothly with the larger images as it does with smaller variations. So I'm not sure what would constitute a stack being 'much larger' than it needs to be - in my first case it was the main stack that was large and now it is the images folder that is large - either way the download is going to be the same size and be too big for
> cellular download (which is why I believe Apple has that warning in the first place.) I would not think that 14 retina sized images on 14 different cards is too large for a mobile app and that instead they must be referenced and that that would be a requirement. Normally I think if it was like 50 images it should be referenced but not just 14. Most LC projects I have seen all use lower quality images or regular 1024 images enlarged for retina via code, but they are definitely not retina images.
> 
> All of that said, I think what you stated is spot on and should be included in a best practices type document somewhere for mobile development. Maybe with some recommendations for audio and compression comparisons.
> 
> Thanks,
> 
> Tom