This is a question for the spring-native team (asking here instead of creating an issue in github).
I am trying as hard as I can to understand exactly the meaning, effects and all reasons of having to make all the preparation of the BeanFactory at build time.
I suppose it would not make sense to try to build an application ready to evaluate at runtime all the possible conditions of all AutoConfigurations of spring-boot. Countless hints would be needed, and the footprint would be unecessarily high.
However, I wonder whether would be possible for spring-native to create an application capable of evaluating, at runtime, at least some specific conditions, which would be specified by the developer at build time. Among all conditions of org.springframework.boot.autoconfigure.condition, supporting "just" @ConditionalOnProperty would be a game changer.
The point is about applications that may be installed in distinct environments. The company I work for makes several software products, which may be installed not only in distinct clouds, but may also integrate with different pieces of middlewares (for instance different message brokers). We use @ConditionalOnProperty heavily throughout all applications. Without its support, I cannot see how we could migrate to spring-native.
The idea would be the developer to indicate somehow (maybe as hints) specific classes anoted with @ConditionalOnProperty which should be processed in runtime.
Of course, the developer would be willing to pay the price of having a footprint/image with possible unused code.
Apologies if this idea does not even makes sense with the current principles of spring-native.