Posted on by

Access builds for iOS 6 Beta

Everyone is highly anticipating Apple’s “special event” next week. Presumably it’s to announce the release of iPhone 5. If history is guide, Apple will release iOS 6 in conjunction with their new iPhone. So starting today, we are enabling the ability to test your Corona apps on iOS 6 Beta 4.

To start building and testing, you’ll need several things:

  • Be enrolled in Apple’s iOS Developer Program (i.e. pay the $99 fee) and therefore abide by Apple’s NDA.
  • Install XCode 4.5 Beta.
  • Install iOS 6 Beta on your iPhone or iPad
  • Corona daily build 900 or higher.

Starting in daily build 900, you’ll notice a special pull down menu in the iOS build dialog (see attached image).

Because the final version of iOS 6 is still in flux, we are disallowing distribution builds (ad hoc or store). This way, you don’t accidentally build and upload the wrong build. There’s also that darn Apple NDA, which means the builds are for your internal use only.

Faster build times (i.e. avoiding pngcrush)

On Friday, I got an e-mail from Graham complaining that because he had 1000 png files, Apple’s PNG optimizer for iOS (a.k.a. pngcrush) was making the device build times ridiculously long.

The challenge: could we reduce build times, but also preserve the optimization (we want Corona apps to look the same as if you built them with XCode directly)?

We think we found a great solution. On developer builds (i.e. those using an “iPhone Developer” signing identity), we skip the optimization and just copy the PNGs. On distribution builds, we perform the pngcrush step as before.

The thinking was that you’re iterating when you do developer builds, so let’s help you iterate faster. When you’re ready to ship, you’ll be signing with “iPhone Distribution”, so we do the pngcrush step as before — you’ll deal with the slowdown, but you benefit from the standard PNG optimizations.

If you’re an Enterprise user, we are giving you the ability to skip the PNG optimization too. Just insert the following line at the top of the “Compile” build phase:

export CORONA_COPY_PNG_PRESERVE="--preserve"

There’s more information on the API docs for build 900.

Incidentally, we’ve heard that pngcrush optimization offers little benefit there are better alternatives to pngcrush that can significantly reduce png file size. We haven’t had time to benchmark, but if you have interesting stats, let us know!

UPDATE: For large projects, build times decrease by 10x, e.g. 20 minutes => 2 minutes!


Posted by . Thanks for reading...

16 Responses to “Corona: Building for iOS 6 Beta + Avoiding pngcrush delays”

  1. George

    From what I understand, the xcode pngcrush process is in order to reduce iOS load times by transforming png’s to a special format with pre-calculated alpha values. http://iphonedevelopment.blogspot.co.nz/2008/10/iphone-optimized-pngs.html It sounds like disabling this feature for dev builds may cause reduced performance in those builds and possibly other inconsistencies. It might still be worth the time saved waiting for the builds to finish, but it’s definitely something to be on the lookout for.

    Reply
    • Walter

      That’s why the distribution builds (for store) continue to go through pngcrush. Their akin to a “Release” build. All optimizations on, debug code in Lua stripped, etc.

      For dev builds, you may experience slightly slower load times, but we think of them as “debug” builds. Readable Lua stack traces (available starting with the last public release, 894) and faster build times.

      Reply
  2. Graham Ranson

    Wow Walter, that was a fast turn around time on this, thanks! Will be giving it a spin when I get into the office later, I think Forever Lost should be a good test case for this speed up :-)

    Reply
  3. @CraftyDeano

    Great stuff Walter & Team, was a little bug-bare of mine when PNG Crush would cause my Mac to heat up and fans going. Faster builds and cooler laptop sounds like a winner :)

    Reply
  4. Joakim

    Hmmm, what happens to the file size? I am sharing my beta app through testflightapp and I guess this will force me to use more bandwidth both for me and my users? If so, then it would have been better with a checkbox in the build dialog…

    Joakim

    Reply
    • Walter

      Joakim, for beta testers, you can sign with “iPhone Distribution” (i.e. ad hoc distribution). Your app then builds the same as before, including the pngcrush optimization.

      Reply
  5. Joakim

    Just verified the filesize and it was almost identical when zipped and renamed to an .ipa. I guess that the graphics cant be much more compressed with both crucnh and zip. I could not determ if the loading time was affected, but the buildtime was much faster. So I am really fine with this :)

    Joakim

    Reply
  6. Rob Miracle

    I’m starting up a new project with a collaborator. A du -sh on my source folder shows 27mb of code. I did an Android build and it was 17mb. Using an Ad Hoc distribution profile the iOS build is 42MB.

    I don’t know why my app grew so much. I doubt that the Corona code is responsible for 15mb of code space, so I’m wondering if for some reason png crush isn’t running for adHoc builds. This is the new message I get:

    Compressing/copying PNG /Users/rmiracle/Projects/…..

    So I don’t know if I’m copying or pngcrushing the file. I only have about 1/4th of the resources or less so my client is panicking when seeing the file size.

    Reply
  7. Dario

    Would be useful to have a checkbox to disable compression in build phase also for distribution. The final app size affects both the time between purchase and download from the store and the space used on the device. In my opinion these are key features for the initial success of an app. By the way you can always re-enable pngcrush in case of bad performance.

    Reply
  8. mateosolares

    I released an app using CoronaSDK 2012.945. It has a problem where one graphic that should be transparent, instead has solid black pixels.

    In all my dev builds, and in an Ad Hoc Test Flight App build, there is no such problem.

    Could this possibly be a PNG corruption related to the changes you describe here?

    Reply

Leave a Reply

  • (Will Not Be Published)