blog/platform-apis-in-the-core/

[giscus[bot]]

blog/platform-apis-in-the-core/

Deeper AI integration in the framework core, modern authentication via OAuth / OIDC and WebAuthn passkeys driven from the system browser, and a few smaller additions (WiFi / connectivity, share-sheet result callbacks) alongside.

https://www.codenameone.com/blog/platform-apis-in-the-core/

[jsfan3]

First of all, Shai, I want to say how impressed I am by the recent evolution of Codename One. The amount of progress lately is honestly remarkable — almost hard to believe for those of us who have followed the project for a long time. It is great to see Codename One continuing to modernize while still preserving its original promise of productive cross-platform development.

I would like to add one security-related consideration to the part about LLM API keys, as an integration to the very useful information you already provided.

Fetching the key from a backend and storing it securely on the device is certainly much better than hardcoding it into the app binary. However, for a production app using a shared provider API key, I wonder whether the safest architecture would be to avoid sending that key to the mobile device at all.

In other words, instead of:

mobile app → fetch LLM key → call LLM provider directly

I would normally prefer:

mobile app → authenticated request to my backend → backend calls the LLM provider → backend returns the response to the app

This way, the actual OpenAI/Anthropic/Gemini/etc. key never leaves the server. The mobile app only holds the user/session credentials needed to authenticate with my own backend, while the backend can enforce quotas, rate limits, model restrictions, prompt filtering, logging, abuse detection, and key rotation.

SecureStorage, Keychain, and Android Keystore are very useful tools, of course, but once a bearer token is delivered to a client device, it should probably be considered potentially extractable by a sufficiently motivated attacker, especially on a rooted/jailbroken or instrumented device.

Again, this is not meant as a criticism of the article — quite the opposite. The post is extremely valuable, and I am adding this only as a security nuance that may be worth considering depending on the deployment model.

[shai-almog]

Thanks!

100% it's much better to do whatever you can in the server. I think the main use case here is when an end user already has his own API key or an API key source they can fetch through an OAuth process in a 3rd party site. At that point you don't want to send the key to your server and keep it with the user.