size of libIceObjC

in Help Center
Ice works great, and I'm so impressed with it on mobile devices like the iPhone. One minor challenge I'm having is with libIceObjC - it's rather large:
-rwxr-xr-x 1 lwelsh staff 7392416 Mar 17 16:45 libIceObjC.0.1.0.dylib
It's over 7 MB which significantly increases the size of our application bundle.
Is there a way besides the default build which can make it substantially smaller?
Would using a static library help (I can't imagine an app would pull-in more than 7MB of Ice objects when linking with static libIceObjC.a - there just doesn't seem to me that much source going into libIceObjC)?
How about linking directly with selected objects from the build forming libIceObjC (would it be too hard to collect the required objects)?
A side question - will Apple allow an app bundle with a dynamic shared library such as libIceObjC (I had heard these were not allowed)? That concern, combined with hope that the static version of the libIceObjC library would be smaller, tempts me to switch to using a static library, but linking with the static libIceObjC library diminishes (as documented) xcode's debugging capabilities of an app using Ice (unless that's been rectified). Perhaps the correct solution is to link with a dynamic library for development and link with a static library for release?
-rwxr-xr-x 1 lwelsh staff 7392416 Mar 17 16:45 libIceObjC.0.1.0.dylib
It's over 7 MB which significantly increases the size of our application bundle.
Is there a way besides the default build which can make it substantially smaller?
Would using a static library help (I can't imagine an app would pull-in more than 7MB of Ice objects when linking with static libIceObjC.a - there just doesn't seem to me that much source going into libIceObjC)?
How about linking directly with selected objects from the build forming libIceObjC (would it be too hard to collect the required objects)?
A side question - will Apple allow an app bundle with a dynamic shared library such as libIceObjC (I had heard these were not allowed)? That concern, combined with hope that the static version of the libIceObjC library would be smaller, tempts me to switch to using a static library, but linking with the static libIceObjC library diminishes (as documented) xcode's debugging capabilities of an app using Ice (unless that's been rectified). Perhaps the correct solution is to link with a dynamic library for development and link with a static library for release?
0
Comments
I am not aware of Apple disallowing dynamic linking. Where did you hear this? I'm very interested as well. I would hate to wait a week for our app to be denied simply because of the way it's linked.
There are two options in Make.rules for IceTouch: OPTIMIZE_SIZE and OPTIMIZE_SPEED. I've tried out both; OPTIMIZE_SIZE does not seem to reduce the footprint. A strange thing that I noticed, however: if you build with OPTIMIZE_SPEED, you actually get a smaller binary!
One easy way to test out a static build is to add a new target to your project. You can point this target to an alternate IceTouch build. That way you don't need to give up debugging altogether - just toggle between targets. I'm planning to do this soon as we approach release.
Pete
Although, I got a warning about code signature doing this.
Edit: LOL yeah, scratch the strip! I can't link my app to the stripped version. Perhaps I used to wrong flags or the codesign is the issue.
Pete
I had proposed using it for our iPhone app, but was nixed because our app's executable file size went from 2.1MB to 4.5MB with Ice (we were also hoping for bi-directional compression). I tried everything I knew of - recompiling libIceObjC with various optimizations, static and dynamic, stripping, etc.
Perhaps there's something in 1.0 that helps, or maybe I was doing something wrong. Happy to hear of others' experience WRT to lib/app size, or of course any advice!