Archived
This forum has been archived. Please start a new discussion on GitHub.
size of libIceObjC
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
-
Hi Lance,
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.
Pete0 -
Also have you tried to strip your lib?
-rwxr-xr-x 1 pete staff 3641152 Apr 9 19:04 libIceObjC.0.1.0.dylib petes-p35c-ds3r:lib pete$ strip -u -r libIceObjC.0.1.0.dylib -rwxr-xr-x 1 pete staff 3218016 Apr 9 19:07 libIceObjC.0.1.0.dylib
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.
Pete0 -
If you strip the lib, as it says the code signature is invalidated and the app will not load. You might be able to sign the library _after_ stripping it though. With respect to static libraries it may help since this will allow the linked to strip anything out that is not needed, and you won't have to deal with signing the shared library itself. Currently, there is no advantage to using a dynamic library either since the library cannot be shared between different iPhone applications (for that matter you cannot have multiple applications running at the same time anyway).0
-
Congratulations on the release of IceTouch 1.0! The prerelease was great and I look forward to using it in the future.
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!0 -
We didn't make any effort to reduce the size of IceTouch. We measured the size of the hello demo, and it was 3.2 MB with IceTouch 1.0. Given that an iPhone has a minimum of 8G storage, I don't think that the size is a big concern. Note that if you need for some reason a much reduced implementation for commercial usage, you can discuss this further with sales@zeroc.com.0
