Natives options on the customized download page on LWJGL.com

Well, if you refer to the official LWJGL website, it does say it could support "Linux arm64", which Android is based on. However, if you take a look into this issue, you should be able to understand more: the support for Android is not fully integrated. It clearly shows that it is still not a working direction to support mobile platforms using Java and LWJGL. At the moment, it might not be a good idea to use Vulkan, as the development can be complex and problematic as well. LWJGL may also not work well on Android. So, OpenGL would still be chosen in this sense while there is no need to use OpenGL ES.

Java bytecode interactions with OS through JVM (source)

You may think we can "compile" the code to platforms that do not support JVM by themselves, but I would still not suggest that. Certainly, it is not an optimal solution. JVM, or Java Virtual Machine, is literally a kind of virtual machine, coming with a runtime. Under such runtime, it executes the Java bytecodes rather than machine codes or other things, and the runtime operates with the OS and other entities. Hence, optimization and functionalities often rely on the runtime, while LWJGL is optimizing based on it. In this sense, compiling to platforms without JVM support is unable to guarantee Java program support (packaging is different from this), so when there could be potential incompatibilities and potential stealthy bugs, why should we use this way for production? Thus, it can just be adding vast amounts of work without great benefit blindly.

Then, for the library or framework choice, we would choose LWJGL mainly because Minecraft uses it. What about other libraries? I know there is GLFW, but I prefer not to use it instead of LWJGL since LWJGL already utilizes GLFW for OpenGL support. So, why use a library over a mature library using it? It renders it pointless. Anyway, LWJGL already made bindings to it, and we even make more use of other supported features from LWJGL like bindings, so we can just go with LWJGL. There is no more discussion about other platforms anymore. Thus, the choice is over.

JVM Architecture Diagram (source)

By the way, even when working on the Java project, we can still build a native library to make use of the language or runtime advantages. Like using Rust for computation-intensive tasks such as physics. As C/C++/Rust is not really object-oriented, the memory management can be optimized quite well without the garbage collection part, causing some potential performance issues. Here, the Java part could be reduced a bit while increasing performance.

In addition, if you say bindings to libraries are just as similar as binding other platform libraries, I would not say it is entirely wrong, but I would choose not to stick with it. It eventually falls to the question of how it is executed in production regardless of libraries. Native libraries are supposed to be supported, but not the JVM. For example, there is GraalVM, which can be considered to be used to compile native executables or images, but it is not generally a satisfactory direction for normal software, especially games. It is not always clever to cross-compile anything to anything since not everything is truly compatible with each other, making it even harder to compile code from one architecture to another.

Different plans for Minicraft+ Java and Cross-Platform projects

Moreover, we plan to support both client and server for desktops but no server for other platforms. Indeed, servers are usually hosted on "servers" or computers, though there might be "LAN servers" locally like in Minecraft. Maybe it is still possible to standardize the protocols between different versions, but they may have minor differences in functionalities. For this Java project, we can then focus on both implementations for better workflows to get it done. Working on supporting other platforms is not what we should be doing now, as that is for much later.

Speaking of differences, there could still be differences between them; one of them is modding. Compared with desktops and JVM, modding in mobiles and consoles is not quite optimistic, except with APIs (like plugins, etc.), like some officially moddable games nowadays. It is also possible to have APIs like in Bedrock, which may not support "modding" (with mod loaders). I may discuss more about the topic of modding Minicraft+ later when it is the time.

Apart from platforms, we are planning to upgrade the Java version of the Java project. It is a big change and a must for our continuous development, though it could be a concern to some users. We will do it soon for our later 2.3 version progress, you may head over here for more information.

Currently, this project is still targeting desktops, and bare Java is not quite optimal (without Android API) with mobiles. While there are always ways to do tasks generally in every programming language theoretically, it is more vital to examine how easy/hard and how complex to implement in reality. Working in production does not like plane experimenting, where costs and efficiency are somehow not in high priority. There is no point in going for a tough path when we do not have much effort and a continuous amount of resources, but instead, a way more efficient and optimal (an expected way) method, which could be more productive and realizable.

Cover asset credits:

• https://github.com/MinicraftPlus/minicraft-plus-revived

• https://commons.wikimedia.org/wiki/File:LWJGL_logo.svg

• https://www.freepik.com/icon/cross-platform_9872430

• https://commons.wikimedia.org/wiki/File:Android_Robot_Head_2023.svg

• https://commons.wikimedia.org/wiki/File:Apple_iPhone.svg

• https://en.wikipedia.org/wiki/File:Java_programming_language_logo.svg

Let us not talk about whether we should do it on iOS or Android first, which would make the issue more complicated. Taking an existing example of Minecraft, we all know quite a number of functions are unavailable on the Bedrock version or mobile, including debugging (F3 keys) and some hotkeys. When taking advantage of touch screens, the user should be able to interact with the world without being restricted to "fixed buttons" (only controlled by pressing them) to make the best use of equipment. This is, of course, something to consider, but it is not the main thing to talk about, as all the non-trivial features should still be implemented in real case. It is also not user-friendly to just add arrow buttons on the screen (a common way to do) as you can see in a lot of mobile ports but instead make use of and fit the touch screen. Obviously, the current way to handle menus is not touch screen-friendly, wherefore it is something to tackle first.

In addition, there is not only the compatibility of controls, but also issues of the devices. There are explicit differences between mobile devices and computers, notably the storage spaces. It is also why it is really hard to support both mobile and desktop simultaneously for libraries with native libraries as of maintenance complexity. Supporting Android requires its API in addition to JDK, so if there comes a library, it does not need to support Android API completely. We have already decided to go on LWJGL (LWJGL 3 does not support mobiles) on the coming major update, and in this manner it is very difficult to also support mobile. Moreover, it is not something really ideal for the current project structure, saying of project or code organization. Certainly, we must separate native parts and core engine parts, which can be much more complex. Furthermore, we really know we do not have much resources working on this project, whilst it could certainly skyrocket the amount of work. Despite the fact that Android is using Java (JVM actually) for its engine, the API is majorly different from what we do on a desktop. Therefore, we cannot do mobile support in this Java repository.

To not separate the mobile community and not discriminate against particular mobile users, both major platforms should be supported at once in my opinion. As just a general software developer, without a strong opinion about how people should choose platforms, both should be supported when doing software support. It is the case when Java is not the first option for programming personally. Well, there is indeed a game called Mindustry supporting desktops and Android without iOS, but however, it might generally not be a great practice when doing with general wide support. Users choose hardware, then software. When users have their reasons to choose, doing so can reduce the amount of market unless someone does not care a bit. It is not something to "compile" code for another platform that does not at all support Java, since it is not something intended, and how would one benefit from it nowadays? Yes, we can compile the code to support iOS, but it is certainly not the most ideal and compatible way. Quality of life and code is important, as is quality of product compatibility. As, we would not like seeing bugs or, in general, something we do not expect or plan to happen, bugging out users.

As forementioned, we know in this Java repository that we would not support mobiles. Then, how should we do then? When we come to more resources, it can be something to consider, which is starting another project, but in another language. We know Minecraft has Bedrock Edition. Likewise, the project would be able to support more platforms, even desktops, when needed. It is a question whether to separate the protocols and structures for either project, but it is definitely something to consider only when it is the time. In tradition, it would be written in C/C++, but now we have Rust to come over this. Rust can be useful and safe when talking about memory and resource safety, so in general, fewer bugs, especially serious bugs, would be introduced, and which will be the focus. When it is compiled, it can also be used like a native library, and thus it can be ported to various subprojects aiming different platforms for best compatible supports, including native functions. Consequently, it is the core engine written in Rust and subprojects written in their respective best languages. Since Minicraft was already in Java, the "mother" Minicraft+ project should still be in Java, where we can still support mods flexibly and in its own type of economy, like the Minecraft one's. Right now, due to its complexity and our resource limitations, we cannot do it in the near future, but it would be absolutely a better way to do.

At the moment, this is all we should do with mobile porting. When we have the engine written in Rust, consoles that clearly do not support JVM can also be supported. We will not stop others from starting the project themselves, but I would hope it to be maintained. It is really hard to say how long it would take for rewriting it in Rust, but the project structure should still be well-planned, or else it would just be a mess again, like the circumstance before in this Java project. Along the way, I have been working on enhancing and planning the structure of the project and the standardized quality of the code. For a long-living project, continuous maintenance is obviously important, and hence, when you do not have much time and effort, even people and resources, just consider it seriously. We have already swapped the maintainer couples of times and continued expanding the project, and why not?

Cover asset credits:

• https://github.com/MinicraftPlus/minicraft-plus-revived

• https://commons.wikimedia.org/wiki/File:Mobile-Smartphone-icon.png

• https://www.trustedreviews.com/reviews/google-pixel-7