iOS Build Timeout During Optimizer Phase - "unused Method cull removed 9357 methods in 482 seconds"

[luisguga]

Hi,

I'm using a Codename One Maven project with Codename One version 7.0.218.

The project was previously building successfully for iOS.

Recently, I added a very small Android Native Interface (AndroidStatusBarNative) used only to set LIGHT_STATUS_BAR on Android. The Android build works correctly, but, after this change, when building for iOS I'm getting a timeout during the optimization phase.
The iOS build no longer completes and log ends with the following messages:

---

74 native files74 native files
Native files total 1833KNative files total 1833K
Optimizer On: Removing unused methods and classes...
Optimizer On: Removing unused methods and classes...
cullClasses()
cullClasses()
cullClasses()cullClasses()
cullClasses()
cullClasses()
cullClasses()
cullClasses()
cullClasses()
cullClasses()
unused Method cull removed 9357 methods in 482 seconds
unused Method cull removed 9357 methods in 482 seconds
Timeout reached. Destroying process
Process timed out

There are no compilation errors before this point.

I'm trying to determine whether:

• This timeout is related to the Native Interface changes.
• The optimizer is taking unusually long because of something in my project.
• There is a known issue or workaround for this timeout during iOS builds.

Has anyone experienced a similar issue or knows what could cause the optimizer to spend so much time in the "Removing unused methods and classes" phase?

Any suggestions would be appreciated.

Thanks!

[shai-almog]

I understand that this is an error from the build server, right? Can you send the link to the log in the website chat so we can look at it?

[luisguga]

Yes, this is from the Codename One build server.

I'll send you the build log link through the website chat.

Thank you for taking a look.

[shai-almog]

Thanks. Can you see if it works now?

We pushed a fix. It seems the ParparVM process was choking on a large class tree to a large part because of the growth of the Codename One API over the past few months. The solution we're trying is simply increasing the heap which would hopefully be enough to get it over the hurdle

[luisguga]

Thank you very much, Shai.

I really appreciate your help and the quick response. I wasn't expecting a server-side fix so fast.
I'll trigger a new iOS build and report back with the results.

Thanks again to you and the Codename One team for the great support.

[luisguga]

Hi Shai,

Thank you for the quick fix.

I triggered a new iOS build, but unfortunately the same timeout still seems to be happening.

The log still ends with:

74 native files74 native files

Native files total 1833K
Native files total 1833K
Optimizer On: Removing unused methods and classes...
Optimizer On: Removing unused methods and classes...
cullClasses()
cullClasses()
cullClasses()
cullClasses()
cullClasses()cullClasses()

cullClasses()
cullClasses()
cullClasses()
cullClasses()
unused Method cull removed 9357 methods in 482 seconds
unused Method cull removed 9357 methods in 482 seconds
Timeout reached. Destroying process
Process timed out

Should I send you the new build log link through the website chat as well?

Thanks again.

[shai-almog]

We're having a hard time reproducing this as a test case but our current theory relates to the scale of native sources imported by dependencies that ran into an inefficiency in ParparVM. We pushed an update that should fix that issue.

[shai-almog]

That seems to be a problem with your code. It looks like you have a native interface called AndroidStatusBarNative and it's missing an iOS implementation.

[luisguga]

Hi Shai, I actually do have the iOS dummy implementation files, and they are named using the package-style name shown in the build error: com_iw_mobile_nativeimpl_AndroidStatusBarNativeImpl.h com_iw_mobile_nativeimpl_AndroidStatusBarNativeImpl.m Currently they are located in: ios/src/main/native in my Maven project. So I suspect the issue may be that I placed them in the wrong directory, or that Maven expects iOS native interface files in a different location. Could you please confirm the correct location for these .h/.m files in a Codename One Maven project? Thanks! Em sáb., 13 de jun. de 2026 às 21:54, Shai Almog ***@***.***> escreveu:

…

That seems to be a problem with your code. It looks like you have a native interface called AndroidStatusBarNative and it's missing an iOS implementation. — Reply to this email directly, view it on GitHub <#5235?email_source=notifications&email_token=A6F7MAPCZCFICYD233BV3CD47XZTFA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZSHEZTQNRQUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-17293860>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A6F7MAL3RPTIV6FF3C2S5P347XZTFAVCNFSNUABHKJSXA33TNF2G64TZHMZTEOJXGM2DMNZ3IRUXGY3VONZWS33OHMYTAMRUG4YTKOFBOYBA> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/A6F7MAPQUSGOWQHD3CYCVCD47XZTFA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZSHEZTQNRQUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/A6F7MAJYCNBDWTR4YDHWYNL47XZTFA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZSHEZTQNRQUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[shai-almog]

You need to use the stub generator when doing that since this is a pretty flaky task. Also most of the AndroidStatusBar stuff can probably be done using build hints and doesn't require native code.

The default location would be ios/src/main/objectivec.

[luisguga]

Thank you, Shai.

Everything is working now.

The timeout issue appears to have been resolved, and the remaining problem was indeed the location of the iOS native files. I had placed the .h/.m files under:

ios/src/main/native

After moving them to:

ios/src/main/objectivec

the iOS build completed successfully.

Thank you for your help, your quick responses, and for pointing me in the right direction.

[luisguga]

One additional note regarding your comment about build hints:
"...Also most of the AndroidStatusBar stuff can probably be done using build hints and doesn't require native code."

Before implementing the Native Interface, I tried several approaches using build hints without success. My goal was simply to make the Android status bar icons/text dark, since the top area of my application is white.

I tried both:

• android.style with windowLightStatusBar
• Theme.MaterialComponents.Light.NoActionBar with android.theme_inject

but in all cases the status bar text/icons remained white.

The only solution that worked consistently was using a Native Interface that calls WindowInsetsController.APPEARANCE_LIGHT_STATUS_BARS (Android 11+) and SYSTEM_UI_FLAG_LIGHT_STATUS_BAR (Android 6+), triggered from the Form ShowListener.

Based on the native code that worked, is there a build hint equivalent that applies SYSTEM_UI_FLAG_LIGHT_STATUS_BAR / APPEARANCE_LIGHT_STATUS_BARS at runtime?

I tried android:windowLightStatusBar in the Android theme, but it didn't take effect, possibly because Codename One changes the system UI flags after the Activity is created.

Just mentioning this in case it helps identify why the build hints were not taking effect in my project.

[shai-almog]

We should probably make this more discoverable: https://www.codenameone.com/developer-guide/#_android_lollipop_actionbar_customization