Size of JRE.xcframework exceeds 75MB limit of appstoreconnect about j2objc HOT 2 OPEN

The problem becomes more clear when I just built my framework. If I build my framework with architecture arm64_32 my build product becomes 37MB

If I build my framework with architectures arm64_32 and armv7k my built product become 72mb. My app that bundles this framework adds a few more MB's and exceeds then the 75mb

I would expect that the app thinning process would only select the relevant slice of my framework / the JRE framework but it doesnt seem to do that since I'm hitting the 75MB limit.

ChatCPT:
"When you build a framework for multiple architectures, the resulting binary can contain slices for each supported architecture. These slices include code specifically compiled for each architecture, allowing the framework to be used on a variety of devices. When you create a thinned IPA for your app, the App Store will only include the necessary slices for the target device.

However, the size of the thinned IPA can still be affected by the inclusion of additional architectures in your framework. This is because the thinned IPA needs to include all the necessary slices for the target architecture, even if some of them are not used.

In your case, when you build the framework for both arm64_32 and armv7k, the resulting binary includes slices for both architectures. When you use this framework in your app and create a thinned IPA for a specific device, the IPA needs to include the slices for that device's architecture. If the device supports both arm64_32 and armv7k, the thinned IPA will include both sets of slices, leading to a larger IPA size.

On the other hand, when you build the framework only for arm64_32, the resulting binary only includes slices for that architecture. When you create a thinned IPA for a specific device, it will only include the slices for that architecture, resulting in a smaller IPA size.

To reduce the size of the thinned IPA, you may consider building the framework for the specific architectures you intend to support in your app. If you don't need to support older devices that use armv7k, you can exclude that architecture from your build to reduce the size of the resulting thinned IPA."

So if this is expected, then the JRE.xcframework for arm64_32 and armv7k already takes almost 70MB of my watch app leaving only 5MB for the rest..

I realize now that I also have the option, instead of using the JRE xcframework to use the .a files once again, and only linking in jre_core.. but still that will also result in significant size of the IPA's when building for more arechitectures.

from j2objc.

Most iOS projects build with the -ObjC flag (the default in new Xcode projects), which tells the linker to include every .o file in every static library whether any are used or not. That flag makes it easier to build apps that dynamically load classes and/or define Objective-C categories. The cost is that apps that are built with static libraries, like j2objc, can be bigger due to unused code being included.

Compounding this problem is that the JRE is huge, including the JRE framework makes apps much bigger. So linking with the JRE.framework is really just for development and testing. Published apps need to be trimmed down somehow.

The easiest thing to try is to remove the -ObjC flag and test the app thoroughly to verify that any code using dynamically loaded classes still works (look for Class.forName(<class-name>) calls). If you define any Objective-C categories, those need to be tested as well. Unfortunately, not all apps have rigorous integration tests, so those teams want to keep that flag even though it causes bloat.

That's why the JRE subset libraries exist. We broke the JRE into chunks where possible, consisting of a jre_core (the minimum all j2objc apps need), plus subsets for JRE specifics like networking, concurrency, XML, NIO, etc. You'll see them all by listing j2objc/dist/lib/iphone/libjre_*.a. The list of which JRE classes are in which subsets is defined in j2objc/jre_emul/jre_sources.mk, but it's often easier to start with core and inspect the "missing symbol" linker errors. Your app uses XML? Then it probably needs to link in libjre_xml.a. java.util.concurrent references? That's libjre_concurrent.a. And so on...

This isn't a perfect solution, though, as some JRE subsets reference other subsets. The subset for the java.time package is the worst, because the Android team implemented it by porting a large subset of ICU4J, causing the libjre_time.a to add ~45Mb to an app. Many teams therefore have switched to JodaTime, which though it's also big, at least just contains the code needed for time and calendar support.

If you need JRE subset frameworks instead of libraries, in the j2objc/jre_emul directory run build_subset_frameworks.sh.

from j2objc.