DEV Community: Shai Almog

Smaller Simpler Maven Projects

Shai Almog — Thu, 22 Oct 2026 17:57:54 +0000

Opening a new application should show you the application. A directory full of platform modules makes you learn the build's structure before you have written a screen.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

Last week we added smaller Gradle projects. Maven now starts small too. The application archetype defaults to the root POM and common, with no platform modules. You can still run the simulator and build the target apps. This closes our weekly release series.

The default tree matches the first task

The relevant part of a new project looks like this:

my-app/
    pom.xml
    common/
        pom.xml
        codenameone_settings.properties
        src/main/java/
        src/main/resources/

This is a shortened tree, not a count of every generated resource or launcher script. The structural count is two POMs. Source, CSS and resources remain where an existing Maven user expects them.

When a platform has no module, common handles its build. These commands keep their meaning:

mvn cn1:run
mvn package -Dcodename1.platform=android
mvn package -Pexecutable-jar -Dcodename1.platform=javase

The desktop executable JAR goes under common/target in this layout. Platform modules become useful when a target needs independent dependencies or plugins, rather than because every possible target needs a directory on day one.

A native implementation does not need another POM

mvn cn1:generate-native-interfaces still creates platform-specific source directories. An Android implementation can live under android/src/main/java, and an iOS implementation under ios/src/main/objectivec, without either directory becoming a Maven module.

The build treats a platform as a separate module when <platform>/pom.xml exists. Native source directories alone do not make that decision. JavaSE implementations are compiled into common/target/cn1-javase/classes, separate from application classes, so they are not accidentally uploaded into a device build.

This also keeps the Android migration introduced on Friday approachable. Imported Android sources live under common/src/main/android; your initial port need not begin by learning every target module's POM.

Ask for the structure you need

The archetype's platformModules property defaults to none. all restores the full platform layout, and a comma-separated value such as javase,android creates only those modules. Its projectType defaults to app; app-with-backend adds the server, and backend-only creates a standalone server project.

For example, these are options to append to your normal archetype generation command, not commands on their own:

-DplatformModules=javase,android
-DprojectType=app-with-backend

A backend-only project has its POM and src/main/java at the root. It needs no empty client beside it:

./mvnw cn1:backend
./mvnw cn1:backend-package

The minimal default applies to newly generated projects using the updated archetype. It does not delete modules from an existing checkout. Before simplifying an older project, check for platform-specific build configuration rather than assuming its POMs are empty scaffolding.

Less structure to explain and inspect

I still prefer Maven's explicit XML for build configuration. I also prefer having less of it to read. Those preferences can coexist.

A smaller project tree helps a new contributor find the code that matters. It also leaves fewer generated configuration files for an LLM to misread when asked to change one screen. That is a reduction in surrounding material, not a guarantee that generated code is correct. Review the diff and run the relevant application behavior just as before.

PR #5937 introduced these project shapes. The current archetype reference defines how target selection and native directories work. Start with the default, then add a platform module when you have a concrete setting to put in it.

Discussion

How many of your platform POMs contain configuration you actually maintain?

PGO for Faster Apps and Generational/Adaptive GC

Shai Almog — Wed, 21 Oct 2026 18:01:09 +0000

Your native compiler can optimize an app more effectively when it knows which code actually runs. Profile-guided optimization, or PGO, gives it that information. The build service runs an instrumented version of your application, records its execution and uses the profile to compile the binary your users receive.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

PGO is now a Pro and Enterprise cloud-build feature for iOS, native macOS and native Linux. You enable it with a build hint; the service handles the extra compilation and training. It is a way to improve native performance without rewriting application logic or managing a profiling pipeline yourself.

This release also adds adaptive generational garbage collection to ParparVM. We will start with PGO and how to use it, then look at the GC changes and the memory cost behind their CPU improvements. This continues our weekly release series and last week's object-layout work.

Let your app guide the compiler

An ordinary optimizing compiler has to estimate which branches are common and which functions are worth inlining. PGO replaces some of those estimates with counts from an actual run. Frequently executed code can be placed together and optimized for speed, while code outside those paths can stay compact.

The profile applies to translated Java, Codename One's runtime and your native sources. The instrumented binary stays on the build server. Your users receive the second build, without the training counters.

Turn on PGO for your target

Add the relevant hint to codenameone_settings.properties. This example enables it for iOS and sets a 90-second training period:

codename1.arg.ios.pgo=true
codename1.arg.pgo.trainingSeconds=90

Each target has its own switch:

Build hint	Target	Training environment
`codename1.arg.ios.pgo=true`	iOS device app	Temporary iOS simulator on the build server
`codename1.arg.macos.pgo=true`	Native macOS app	Build server
`codename1.arg.linux.pgo=true`	Native Linux app	Build server with a virtual display

The training period defaults to 60 seconds. Values below 10 or above 300 are brought into that range. Increasing it gives the application longer to exercise its startup work; it does not create user interactions.

If you already subscribe to Pro or Enterprise, enable the hint and submit a supported cloud build. PGO is included in those plans. You can compare plans here. These hints belong to the cloud build service; local builds do not consume them.

Give the training run useful work

The app starts from a clean state and runs unattended. Resource loading, initial layout and painting can contribute to the profile, as can animations, timers and network work that start automatically. Repeated work is particularly useful because the compiler can identify the paths that dominate execution.

Nobody signs in or taps a button during training. If the app stops at a login screen, the profile describes that screen. Code behind it remains correct, but the compiler has no evidence that it is an important execution path. Before enabling PGO, run the app from a clean installation and check what it does without input.

PGO adds build time because it requires two compilations and a training run. Start with a normal Release build and record the time for a representative task. Repeat that task with the profile-guided build on the same device. Check memory and the result of the task as well as elapsed time. The gain depends on how much of your workload the training run reached; we are not assigning a universal speedup percentage to it.

A requested profile-guided build either produces that binary or fails with a reason. An empty profile, a crash during training or an incompatible build mode does not silently produce an ordinary build. The performance guide lists the settings, training rules and incompatible configurations, including debug and simulator-only modes. PR #5945 introduced the build support.

Adaptive GC reduces the work left to run

PGO improves the generated native code. The collector changes reduce how much work that code needs to do. In our allocation workload, the concurrent collector spent time tracing fresh objects and sweeping their slots even when almost none survived.

ParparVM now has an adaptive generational phase. Holding more memory can reduce collection frequency, but it can also make the next full trace or transition much worse. The standard Codename One benchmarks use no PGO, so the following GC results measure the runtime changes separately.

Collect survivors instead of revisiting every allocation

A generational collector concentrates frequent work on young objects, based on the observation that many die quickly. References from older objects to young ones must still be tracked, and surviving objects cannot simply disappear when a young page is reset.

Our hybrid chooses between the existing concurrent path and stop-the-world generational cycles. On eligible multicore processes, it enters after repeated low-survival cycles with allocation demand and a concurrent collector busy for at least half the interval between cycles. Low available memory is an exit condition, not the trigger to enter.

An all-dead young page can be reset in constant time. The allocator's bump path is inline again, and accounting moves from each object to each page where possible. Those changes remove work rather than merely asking another CPU to do it.

A process that has created virtual threads stays concurrent. A registered native thread that the collector cannot hold also prevents these stop-the-world cycles. Pausing only some allocating threads is not a valid stop-the-world algorithm. The runtime implementation enforces those boundaries.

More memory can buy fewer collections

The young-generation budget responds to collection duty. Two successive minors consuming more than 5% of their intervals can grow it; below 1%, it can shrink. Growth is bounded, including by a fraction of host memory. Requiring two busy minors avoids treating one collection delayed by the OS scheduler as proof that the application needs a larger heap.

A larger young generation lets more short-lived objects die before the next collection. That can save CPU. It also leaves more memory resident, and increases the amount of work a later phase may inherit. You have to measure both sides.

Conceptual diagram, not benchmark data. Increasing a budget can reduce frequent collection work while increasing retained memory and the cost of a later scan. The actual curves depend on survival and reference patterns.

One failed transition made this concrete. Deferring the exit decision until the next cycle handed as much as 128 MB of young objects to a concurrent collection. Its fresh-object protection retained them, while application threads kept allocating behind it. The engineering record reports a roughly 500 ms cycle and a page-heap count rising from 3,446 to 10,538 in the affected stress test. The exit decision now runs at the end of the stopped cycle, before application threads resume.

Another attempted concurrent major promoted about 6.4 million dead objects into the old generation. The next minor then spent 260 to 305 ms examining the remembered set. Those are failure observations from the GC engineering record, not advertised pause bounds for the corrected collector.

Read time and memory together

The committed calibration change for PR #5940 gives a useful view of the trade. These are historical gate baselines for objectAllocation, with JDK 25 equal to 1. Lower is better in both columns.

Runner	Time ratio, before → after	Peak memory ratio, before → after
macOS ARM64, three-CPU runner	3.696 → 1.106	0.481 → 0.937
Linux x64, AMD EPYC 7763	5.011 → 1.649	0.370 → 0.370
Linux ARM64, Neoverse N2	3.043 → 3.043	0.239 → 0.378
Windows x64, AMD family 25/model 1	4.932 → 1.559	0.400 → 0.386

The macOS row is the clearest cost: much less allocation time, almost twice the previous memory ratio. Linux ARM64 records more memory with its time baseline unchanged. A value unchanged in the overlay can be a carried-forward baseline; it is not a fresh measurement of zero change. The ratios still show ParparVM slower than JDK 25 on this allocation workload after the improvement.

These are calibration records, not a new controlled before/after experiment. Most selected rows record one calibration run; the Windows row records three. They have no confidence intervals, and later master baselines include further recalibrations. The data CSV and original overlay retain that context. Compare within a runner row; do not rank different machines from these ratios.

The allocation workload is deliberately narrow. It tells us about allocation and collection behavior for that survival pattern, not frame latency, network throughput or every application. A backend using virtual threads also follows the concurrent path, so an allocation microbenchmark's hybrid gain cannot be assigned to that backend.

Make a speed gain part of the next baseline

The performance gate runs paired ParparVM and JDK 25 workloads on Linux x64 and ARM64, Windows x64 and ARM64, and macOS ARM64. It alternates which runtime goes first, verifies output and records median ratios. CPU-specific baselines keep one runner model from silently standing in for another.

For workload timings, the gate uses the fastest measured repetition inside each process; JVM startup is not charged to the workload. Memory is a process peak: footprint on macOS, RSS on Linux and working set on Windows. Those are related measurements, not identical operating-system counters.

A change outside the permitted tolerance fails in either direction. A large improvement needs a reviewed baseline update too, otherwise a later regression could give it back while remaining below the old limit. Each PR owns an overlay, records a reason for an intentional change and names the value it replaces. Merged overlays are folded without changing the resolved baseline.

# Run locally on the appropriate platform and inspect both metrics.
vm/selfhost/ci-perf-gate.sh run macos-arm64 /tmp/cn1-perf
vm/selfhost/ci-perf-gate.sh verdict /tmp/cn1-perf

This comparative gate covers the five host OS/architecture combinations above. It is not a JDK comparison running on an iPhone, Android device or browser. Those ports have their own behavior and screenshot coverage. The port status page exposes the distinction, and PR #5930 explains the baseline workflow.

Keep the gain you measured

PGO and adaptive collection improve different parts of execution. Compare a profile-guided build with a regular build using the same application workflow, and keep the time and memory results together. For compiler and runtime changes, the performance gate gives the next release a baseline to preserve.

Discussion

Which part of your app would benefit most from a profile-guided build: startup, rendering, or repeated background work?

Try Real Java in Your Browser, Compiler Errors Included

Shai Almog — Tue, 20 Oct 2026 18:39:41 +0000

A playground should tell you whether your Java works. A Java-like interpreter can instead teach you which Java it happens to understand. That difference becomes annoying as soon as you paste a record, a lambda or an example with a tricky generic type.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

We rebuilt the Codename One Playground around our in-tree Java compiler. Your code becomes class files, then the ParparVM translator turns those classes into JavaScript inside the page. The running app loads them and updates the preview. Compilation does not send your source to a server.

A compiler running inside its own output

Both the compiler and translator are written in Java. ParparVM translates them into the JavaScript bundle you load when you open the Playground. That bundle can then compile and translate more Java: the code you type.

This is our com.codename1.tools.javac implementation, not the OpenJDK compiler copied into the page. It targets javac's language rules and diagnostics. The compiler conformance tests compare program output and negative cases with the reference compiler.

That distinction matters when reporting a bug. A familiar error message is useful, but agreement on a test corpus does not prove every possible Java program behaves identically.

Paste a record and change it

Open the Playground and replace the Java pane with this script:

record Item(String name, int count) {}

Item item = new Item("Orders", 3);
Form form = new Form("Java in the browser", new BoxLayout(BoxLayout.Y_AXIS));
Label label = new Label(item.name() + ": " + item.count());
Button button = new Button("Show the next count");
button.addActionListener(event ->
        label.setText(item.name() + ": " + (item.count() + 1)));
form.addAll(label, button);
form.show();

The Playground supplies the usual UI imports and supports script-shaped input. Change the constructor's 3 to "three". That is a type error, and the editor can point to it before the app runs. Restore the number and click the button to exercise a listener compiled from your code.

Records, switch expressions, pattern matching and lambdas go through the compiler's type checking and lowering. A record gets explicit methods in bytecode. The translator handles the resulting classes against the API the page actually contains.

Captured from the public Playground on October 8. Clicking the compiled listener changed the label to Orders: 4.

The deliberate mistake reports the constructor mismatch at line 3, column 13. The preview does not run the invalid program.

Keep the API open without keeping everything

A normal app has a known set of reachable classes. The translator removes unused code and can turn some virtual calls into direct calls. The Playground cannot assume that tomorrow's source will only call methods today's bundle already uses.

Its host bundle therefore keeps selected API packages open. Those methods retain predictable names and support subclasses arriving later. A small stub library supplies signatures, generic information and constants to the compiler without supplying a second copy of the implementations.

The compiler, translator and platform internals stay closed to user code, so they can still be reduced and renamed. Incremental translation only emits the new user classes. A later run replaces those definitions without rebuilding the whole application bundle.

Removing the interpreter removed other machinery

BeanShell needed access bridges to call framework code in an environment without its usual reflection support. The old generated access adapters occupied 23,827,851 bytes across 161 Java files, before counting their central registry. The new pipeline removes that registry, BeanShell and its listener and lambda bridges.

That source-file saving is not a browser download measurement. The compiler and translator also add code, and compression changes the transfer size. The repository includes compare-javascript-bundles.sh to compare actual artifacts; use the same build configuration and compression for both. The Playground console reports compile, load and run times so a smaller bundle and a faster edit cycle can be measured separately.

For the example above, one Chromium run on the local Mac reported 1,247 ms compile, 505 ms load and 8 ms run. The invalid version reported 841 ms compile and no load or run. Those are single observations from the deployed Playground, not a warmed benchmark or a before/after speedup. They make the phases visible without attributing an unmeasured gain to the rewrite.

An unfinished edit must be valid input to the tool

A compiler in an editor sees broken programs most of the time: half a string literal, an incomplete method and a generic type with its closing bracket still missing. The conformance suite includes program prefixes so these produce diagnostics rather than exceptions or hangs.

Other gates compare the self-hosted translator's output with the JVM translator byte for byte. Browser tests run samples, edit code, rerun it, navigate forms and provoke listener exceptions. That last case matters: an exception swallowed after a successful compile makes the preview look frozen while the actual failure disappears.

There are limits. The page exposes a supported API, not the whole JDK. Annotation processing and Java modules are absent; native method declarations are rejected. Some library surfaces exist but remain unsupported at runtime, including the browser regex implementation documented in the guide. BeanShell-only share links can now fail compilation.

The Java in the browser chapter explains the pipeline and gates. PR #5938 began this rebuild. Try a small part of your next screen in the live Playground, including a deliberate mistake, and see whether the feedback tells you what you need.

Discussion

Which Java construct do you reach for first when checking whether a playground runs the language you use?

How Do You Test Spring Compatibility?

Shai Almog — Mon, 19 Oct 2026 19:54:58 +0000

The Codename One backend is not Spring compatible. We use similar syntax to ease migration and porting, but familiar annotations do not tell you whether the ported application behaves the same way. Tests do.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

Write those tests in the original Spring application first. Capture the behavior your clients depend on, get the tests passing, then bring the same assertions to Codename One. Here, compatibility means that your application's behavior survives the move. It does not mean that Codename One implements the Spring framework.

The new testing API gives you familiar request builders and assertions for that job. You can run them against the port on the JVM, then check the compiled native backend too.

Establish the behavior in Spring first

Start with an endpoint whose contract you already know. For a Spring application that exposes /greet/{name}, this test records the successful response and what happens for an unknown route:

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.web.servlet.MockMvc;
import org.junit.jupiter.api.Test;

import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.jsonPath;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;

@SpringBootTest
@AutoConfigureMockMvc
class GreetingApiTest {
    @Autowired
    private MockMvc mvc;

    @Test
    void greetsByName() throws Exception {
        mvc.perform(get("/greet/{name}", "Ada"))
                .andExpect(status().isOk())
                .andExpect(jsonPath("$.greeting").value("Hello, Ada"));
    }

    @Test
    void unknownRoutesAreNotFound() throws Exception {
        mvc.perform(get("/nowhere")).andExpect(status().isNotFound());
    }
}

This example uses the Spring Boot 3 test imports. Run it against the original application before porting. If the application protects these routes, configure the test identity to match its access rules rather than disabling security to get a green result.

For a real service, go beyond the successful response. Test validation errors, missing records and denied access. For a write endpoint, verify the stored state as well as the response. Those expectations define what the port must preserve.

Port the test setup, keep the assertions

For the Codename One version, change the framework imports and test annotations. The request inputs and expected results above stay the same:

-import org.springframework.beans.factory.annotation.Autowired;
-import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc;
-import org.springframework.boot.test.context.SpringBootTest;
-import org.springframework.test.web.servlet.MockMvc;
+import com.codename1.backend.annotations.Autowired;
+import com.codename1.backend.test.BackendTest;
+import com.codename1.backend.test.MockMvc;

-import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;
-import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.jsonPath;
-import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;
+import static com.codename1.backend.test.MockMvcRequestBuilders.get;
+import static com.codename1.backend.test.MockMvcResultMatchers.jsonPath;
+import static com.codename1.backend.test.MockMvcResultMatchers.status;

-@SpringBootTest
-@AutoConfigureMockMvc
+@BackendTest
 class GreetingApiTest {

@BackendTest starts the module's application and injects test fields from its generated wiring. MockMvc passes requests through routing, sessions, scoped beans and error handling inside the process. The matching Codename One controller, service and test are in the compiled guide examples.

New backend templates include the test setup. Existing modules need the test dependency and annotation-processing goals in the testing guide. Keep the same fixtures and expected values on both sides. Changing an assertion merely to accept the port's output hides the difference you were trying to detect.

These import changes work for this example. A larger suite can use Spring test features that Codename One does not implement. Port that setup explicitly, and keep track of any case that cannot run yet. Passing the tests demonstrates the behavior they cover, not every possible interaction in the application.

Decide what the test needs to cross

Use MockMvc for request and response behavior without sending that request through a socket. Use TestRestTemplate when the HTTP transport is part of the contract. Both work with the test application's beans.

A test can add a @TestConfiguration and substitute a @Primary bean. That is useful when you need deterministic behavior from a dependency while still testing the controller and generated wiring. It also works in the compiled runner.

@MockitoBean is available on the JVM with Mockito on the test classpath. It cannot follow you into a native binary because Mockito creates classes at runtime. Prefer an explicit test implementation when the same scenario needs to run in both environments.

Security tests can use @WithMockUser or request post-processors. A mocked JWT identity tests authorization after authentication; it does not test signature verification or the token exchange. Keep a real-client integration test for those boundaries, as Saturday's article describes.

Run the same supported tests after compilation

In a project with a backend module:

mvn -pl backend -Dcodename1.platform=backend test
mvn -pl backend -Dcodename1.platform=backend test \
    -Dcn1.backend.compiledTests=true \
    -Dcn1.backend.compiledTests.strict=true

The second command runs Surefire, generates direct test calls and builds a native test binary with the application's generated wiring and native code. It writes TEST-<class>-compiled.xml reports beside the JVM reports. This is a ParparVM test binary; it does not embed JUnit's reflection-based runner.

Strict mode matters when porting a suite. Without it, Mockito-dependent classes can be excluded or reported skipped. Strict mode makes those unsupported cases fail the build so an apparently successful native run does not hide the tests you meant to keep.

The native path needs the backend toolchain, including clang and the OpenSSL, libcurl and nghttp2 headers. It builds on Linux and macOS. Windows has no native backend runner. Run native tests locally as part of assessing your migration.

Account for differences in the test framework

There are no @WebMvcTest slices; each test runs the application. The generated test application excludes management endpoints, MCP and OpenTelemetry exporters even if production configuration enables them. Check those integrations separately.

The compiled runner supports a defined JUnit 5 subset. Nested test classes, Kotlin tests and some selectors cannot simply be carried over. JSONPath supports common property and index operations, not every filter or function. MOCK and NONE still start a loopback listener for the server's runtime tasks, even though MockMvc.perform dispatches in-process.

Keep the Spring run as your reference while you port. Run the same scenarios against the JVM backend, investigate differences, then run the compiled path and inspect both failures and skips. Replace unsupported test machinery with explicit fixtures where practical. A test that never ran cannot tell you whether the migration preserved its behavior.

PR #5932 introduced the framework, and current master adds the security test support. Start with the endpoint whose behavior would be most expensive to get wrong.

Discussion

Which behavior would you test first before porting your Spring application?

Update DB Schema in Production with Flyway like Syntax

Shai Almog — Sun, 18 Oct 2026 16:43:55 +0000

The database on your laptop has today's schema. The database on a customer's phone might be six releases old. Both have to work after the next update, and deleting the customer's data is not a migration strategy.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

Codename One now uses the same migration engine for client databases and the native backend. It follows Flyway-style versioned scripts and history, with build-time registration so the scripts travel inside the app or server. This continues our weekly release series and supplies the tables behind yesterday's security stack.

Give each schema change a place in history

Client scripts live in common/src/main/db/migration. Backend scripts live in src/main/resources/db/migration inside the backend module. For a notes application, the first script might be:

-- V1__create_note.sql
CREATE TABLE note (
    id INTEGER PRIMARY KEY,
    body VARCHAR(2000) NOT NULL
);
CREATE INDEX note_body ON note (body);

A later release adds a timestamp through another file:

-- V2__add_note_created.sql
ALTER TABLE note ADD COLUMN created BIGINT;
UPDATE note SET created = 0 WHERE created IS NULL;

The double underscore separates the version from the description. Versions sort numerically, so 2.10 comes after 2.9. Never edit a versioned SQL script that has shipped. Its recorded checksum lets the engine detect that two installations would otherwise have different definitions of the same version.

Skipping an app release is now ordinary input to the migration engine. It applies the missing versions in order. A repeatable R__description.sql runs after versioned migrations and again when its checksum changes, which suits a view definition. The build catches duplicate versions, malformed filenames and empty scripts before packaging.

Upgrade before the app starts using the database

For the client, migrate immediately after opening the database:

Database db = Display.getInstance().openOrCreate("notes.db");
Migrations.migrate(db);

The imports are com.codename1.db.Database, com.codename1.db.Migrations and com.codename1.ui.Display. Run database work on its owning thread. If a migration moves substantial data, do it off the event dispatch thread and show progress before opening the normal UI.

The annotation ORM's EntityManager.open("notes.db") performs migration for you. The build compiles scripts into generated code, so there is no folder of migration resources for an iOS package to discover at runtime.

An older binary also needs protection from newer data. By default, a future schema causes migration to refuse before changing it. The client guide shows how to handle MigrationException.FUTURE_SCHEMA and ask the user to update. This is safer than hoping an old query happens to survive a downgrade.

Make server startup an ordering guarantee

The backend applies pending migrations before opening its entity manager or accepting application requests. Its database lock coordinates instances starting against the same database. A successful transactional migration records its history row with the schema change.

Use the Maven goals to inspect and validate a deployment before starting it:

mvn -pl backend -Dcodename1.platform=backend cn1:migrate-info
mvn -pl backend -Dcodename1.platform=backend cn1:migrate-validate

The server migration guide also covers applying and repairing migrations. migrate-info reads history without changing it. Keep connection settings pointed at the intended environment before running a mutating goal.

SQL common to SQLite, PostgreSQL and MySQL can live directly in db/migration. Engine-specific variants belong under sqlite, postgresql or mysql, using the same migration filename. MariaDB uses the MySQL variant. Shared machinery does not make different database dialects interchangeable.

The failure case determines the recovery plan

SQLite and PostgreSQL can roll a transactional migration back with its history update. MySQL and MariaDB can commit DDL statements as they execute. A failed script there can leave part of its schema change behind. The engine records failure and refuses to proceed; inspect and correct the database before repairing history.

A SQLite script marked executeInTransaction=false has another boundary: the normal transaction cannot serialize several starting processes across the whole script. Run such a migration from one process before starting the rest. Do not apply the normal locking guarantee to that exception.

A populated database without migration history is also refused by default. Adopt it by explicitly recording a baseline for the version it already implements. A baseline records your assertion about the schema; it does not inspect every column and prove the assertion correct.

The security library registers its own named migration set and separate history table, then runs before application migrations. That lets your scripts depend on its tables without mixing your application's version numbers with the library's.

There are no undo scripts. Write a forward repair migration, and keep tested backups for changes that cannot be reversed from the remaining data. Java migrations have no automatic checksum, so changing an already-applied Java migration will not get the same SQL checksum protection.

Test the upgrade your customers will take

A fresh-database test only proves the easiest path. Keep fixtures for an older supported schema, upgrade them to current, then reopen and verify that nothing applies twice. Add a newer-than-app fixture to test refusal. For important data, assert the values after migration as well as the table shape.

The implementation in PR #5961 provides the engine. Your release history provides the cases that matter. Tomorrow's testing article shows how to keep backend behavior under test while changing runtimes.

Discussion

How far back does your oldest supported installation's database go?

Easy Full Stack Authentication and Login in the Style of Spring

Shai Almog — Sat, 17 Oct 2026 16:27:03 +0000

Three requests leave your app just as its access token expires. If each refreshes independently, the first exchange can invalidate the refresh token the other two are about to use. A login feature becomes a race between requests.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

This week's security work joins the Codename One client and backend around those transitions. The client can coordinate renewal, the server can rotate tokens, and tests can verify what happens after a real request is refused.

Put the access rule beside the route

The backend has Spring-style security chains under com.codename1.backend.security. A chain chooses which requests it handles, then authenticates and authorizes them. This excerpt from the security guide example protects an API using JWT scopes:

@Bean
@Order(1)
SecurityFilterChain api(HttpSecurity http) {
    http.securityMatcher("/api/**")
        .authorizeHttpRequests(auth -> auth
            .requestMatchers("/api/orders/**").hasAuthority("SCOPE_orders:read")
            .anyRequest().authenticated())
        .sessionManagement(session ->
            session.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
        .oauth2ResourceServer(oauth2 -> oauth2.jwt(Customizer.withDefaults()));
    return http.build();
}

Configure the trusted issuer and the audience your API expects. The guide's configuration keys include cn1.security.oauth2.resourceserver.jwt.issuer-uri and cn1.security.oauth2.resourceserver.jwt.audiences. Audience checking is optional unless configured, so set it deliberately when several services share an issuer.

A backend with no SecurityFilterChain bean has no security layer. Adding a dependency does not secure the routes. A stateless chain also has no CSRF filter unless you request one. Session-based browser applications have a different threat model and need the corresponding session and CSRF configuration.

Method rules such as @PreAuthorize are compiled into checks. They can apply to self-calls and private methods because the build weaves them into the method, rather than relying on calls passing through a runtime proxy. The expression language is a supported subset; ACLs, @PostAuthorize and arbitrary expression evaluation are outside it.

Give the client one owner for renewal

Register an installed app as a public OAuth client with an exact redirect URI and PKCE. A client secret embedded in an app would not remain secret. After configuring OidcClient, install an authorizer for the API base URL:

OidcRequestAuthorizer authorizer =
        new OidcRequestAuthorizer(client).install("https://api.example.com/v1");
authorizer.addSignInRequiredListener((source, reason) -> showSignIn());
authorizer.load().ready(saved -> {
    if (saved == null) {
        showSignIn();
    } else {
        showNotes();
    }
});

This is an application excerpt: client is configured with your provider and token store; showSignIn() and showNotes() are your UI methods. Use SecureStorageTokenStore for platform-protected persistence. Plain storage fallback is an explicit option, not something the app should silently enable to make an error disappear.

The authorizer matches the scheme, host and port, then whole path segments. /v1 includes /v1/notes, but not /v10. It covers ordinary ConnectionRequest calls, the REST builder and generated clients through the network layer.

Renewal starts before expiry by default. Requests queued during the exchange wait for its result. If a token-bearing request receives 401, the authorizer can refresh and retry it once; the caller receives the eventual response. A refused refresh ends the session, clears stored tokens and calls the sign-in listener. If your request writes a body from a stream, verify that your implementation can supply it again before depending on a retry.

For redirects followed by Codename One, the token is removed outside the registered origin or path. The current iOS port lets the system follow redirects before application code sees them. Keep protected API redirects within hosts you control; do not infer that every transport has the same redirect interception point.

Choose the state your deployment can share

The backend includes form login, HTTP Basic, API keys, JWT resource servers, OAuth login and authorization-server support. MFA includes TOTP and recovery codes; passkey endpoints use WebAuthn. These are separate mechanisms with separate configuration, not one switch that makes every deployment secure.

Several instances cannot share an in-memory token repository or rate limiter. Declare the database-backed stores when that is your deployment shape. cn1.security.schema.enabled=true belongs in the module's build-time application.properties; it registers the security migrations. It creates tables, but does not select JDBC stores for you.

Refresh tokens and one-use codes must be consumed atomically. Otherwise two instances can both accept the same secret. The JDBC implementations use conditional database operations and their affected-row counts for those decisions. TOTP secrets are sealed under the configured encryption key; password hashes and one-use recovery codes have their own storage rules.

The packaged server links the mechanisms its chains reach. A token-verifying API need not carry login pages and a password store. That is a useful consequence of explicit configuration and dead-code removal, although it does not reduce the need to review the rules you enabled.

Test the failure after the successful login

The end-to-end client tests connect to the HelloCodenameOne backend. BackendTokenRefreshTest deliberately replaces an access token with one the server did not sign. It checks that the generated client receives one successful response after renewal, that the refresh token rotates, and that reusing a spent refresh token ends the session.

That proves more than a mock that always supplies an authenticated user. It exercises the client's networking and token state together with the server's token endpoint and protected route.

Test layer	What it can establish	What it does not establish
Backend `MockMvc` and mock identities	Route and method authorization decisions	A provider login or signature verification when identity is injected
Native client integration tests	Requests, token exchange, renewal and denial against the backend	Every external identity provider or device sign-in surface
Browser-specific tests	Browser networking and credential APIs, including the virtual-authenticator vault test	Passing the native credential/redirect harness unchanged
Port test matrix	The declared cases on each supported target	Every security mechanism on every port

The credential/redirect tests explicitly report a browser skip because the browser owns those cookies and redirects. A green port suite must be read with those skips. WebAuthn PRF bridge coverage uses Chromium's virtual authenticator; it is not a claim that every hardware authenticator supports that extension.

SAML, LDAP, opaque-token introspection and several authorization-server extensions are outside this release. The backend security guide and client identity guide specify the supported surface. PR #5961 connects those pieces; tomorrow we will look at the migrations underneath their persistent stores.

Discussion

Which failure is hardest to reproduce in your sign-in flow: renewal, revocation, or returning from the provider?

Android on iOS, Web & Desktop Efficiently and for Free

Shai Almog — Fri, 16 Oct 2026 17:23:44 +0000

We are not the first to bring Android to iOS. Earlier projects brought Android's runtime along with the application. Dalvik was built for Android, including a just-in-time compiler (JIT) that ordinary iOS apps are not permitted to use. Disabling it removes an important source of Dalvik's performance. Dalvik was designed around interpretation and JIT compilation, not ahead-of-time compilation (AOT), so taking away the JIT leaves an interpreter rather than an optimized native app.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

Our approach is different. We compile the application into native code for iOS and remove the code it does not use. It becomes a proper iOS application, with access to OS capabilities through Codename One APIs and native interfaces. You get native execution, a UI you control and a path to improve the application after the initial port.

You can now compile classic Android apps into native Codename One apps. Activities, XML layouts and AndroidX code work on iOS, desktop and the web through the compatibility layer. Each imported view is a Codename One component underneath, so you can replace screens individually and mix the two APIs as you migrate.

Try the imported gallery in your browser. The same gallery produces an 8.73 MB compressed iOS app bundle, including the compatibility code it uses and the runtime. We built both versions locally; the table below separates the compressed bundle from its unpacked size.

The framework and compatibility layer are open source and free for commercial use. You can build locally with your own tools. The optional cloud build service has free and paid plans.

Coming This Week

Today we cover the Android migration path, with real gallery screens and the build pipeline. This week's follow-ups cover full stack authentication, database upgrades, testing and the tools that make these applications practical to build:

Saturday, October 10: Easy Full Stack Authentication and Login in the Style of Spring. Token renewal, access rules and tests that cross the network.
Sunday, October 11: Update DB Schema in Production with Flyway like Syntax. Ordered migrations for devices that skip releases and servers that share a database.
Monday, October 12: How Do You Test Spring Compatibility?. Write behavior tests in Spring, then keep the same assertions when you port to Codename One.
Tuesday, October 13: Try Real Java in Your Browser, Compiler Errors Included. The compiler and translator now run inside the Playground page.
Wednesday, October 14: PGO for Faster Apps and Generational/Adaptive GC. Profile-guided native builds for Pro and Enterprise, plus adaptive GC and performance gates.
Thursday, October 15: Smaller Simpler Maven Projects. Minimal projects are now the default, with platform modules added when you need them.

Keep the app working while you change it

A migration usually has an awkward middle. The original application still needs releases while its replacement slowly acquires features. For a small team, that can mean maintaining two incomplete products.

The compatibility layer lets you start with the existing application structure. From a Codename One Maven project, import an Android Studio module:

mvn cn1:import-android-project -Dcn1.android.import=/path/to/MyAndroidApp
mvn cn1:run

The importer copies the module's src/main, reconciles its namespace with the manifest and reports which Gradle dependencies the compatibility runtime covers. Read that report before deciding the app is portable. A successful import is the start of testing, not a certificate for every screen.

The Android interop guide covers manual import, Kotlin sources and the supported APIs. Use a Codename One release containing this change, or build current master while it is being released.

What you are looking at

These are captures of the same gallery sources on the same Android 16 emulator, at 720 by 1600 pixels and 320 dpi. The left app uses the Android framework. The right app uses the compatibility layer. They are both Android captures; this comparison measures the rendering difference, not iOS behavior.

There are visible differences. The Codename One Android build uses a narrower bold face, draws under the status bar differently and has its own Material shadows. Custom rendering gives you control over those pixels across platforms; it does not make every widget pixel-identical to Android.

Try the Android gallery in your browser

Open the interactive Android gallery, or download its source project. Tap Count, open Details, then use the overflow menu to try the other screens. This is the imported Android sample compiled to JavaScript, not a video or a recreation in HTML.

The browser build at a 440 by 850 viewport. The counter and activity navigation run through the compatibility layer.

Is it Efficient?

We built the gallery from master revision ebe0e64be3 as an unsigned ARM64 Release device app with Xcode 27.0, then enabled release symbol stripping. It contains the sample's activities and resources, the reachable compatibility code, Codename One and the native runtime.

Artifact	Size, 1 MB = 1,048,576 bytes
ARM64 native executable, stripped	19.19 MB
App bundle, sum of file sizes	22.33 MB
ZIP of that unsigned app bundle	8.73 MB

The build relocated 1,316 compatibility classes and emitted 862 compatibility translation units for this app. Across the whole application, its method-removal pass discarded 24,616 methods, and field elimination removed 220 never-read instance fields. Those counts describe different stages; they are not a measurement of bytes saved by the Android layer alone.

The ZIP is a compression measurement, not an IPA, an App Store download estimate or an installed-device measurement. Signing and distribution change packaging. We built the device binary locally but did not run it on a physical iPhone. The measurement record includes exact byte counts, configuration and the executable hash. The reproduction notes describe the build.

This is the gallery's footprint, not a minimum hello-world figure. It demonstrates what the retained Android-compatible surface costs in a real package without claiming that the package contains the whole Android OS.

How Android code reaches an iPhone

A runtime-container approach preserves an Android execution environment around the app. Our build resolves the supported APIs into the application's own code. There is no Dalvik or ART runtime bundled with this layer.

The resource compiler generates constructors for activities and layout classes. Inflation can call those constructors directly, without discovering classes by reflection. A later pass moves android.*, AndroidX and Material references under the compatibility namespace. Even the Android target uses that relocated implementation, avoiding a collision with the OS classes.

ParparVM can then remove unreachable classes and methods from the native build. Supporting an API in the library does not mean every application must retain every implementation. Resources, reachable screens and native libraries still cost space. This is why an app measurement matters more than the size of the compatibility JAR.

The result is an application you can develop beyond its Android origins. The compatibility layer gets the existing screens running; Codename One APIs and native interfaces give you somewhere to go next.

Replace one screen, keep the next

The following excerpt from the compiled interop example puts an Android custom view inside a Codename One form. androidContext is the installed Android runtime's context, and MyChartView is the example's android.view.View subclass:

android.view.View chart = new MyChartView(androidContext);
form.add(BorderLayout.CENTER, chart.getPeer());

The reverse direction matters too. A Codename One app can install an imported module and start one of its activities. Here SettingsActivity belongs to that module:

AndroidRuntime rt = AndroidRuntime.getInstance();
if (rt == null) {
    rt = AndroidRuntime.install(new com.codename1.generated.android.AndroidAppImpl());
}
Context app = rt.getApplication();
Intent intent = new Intent(app, SettingsActivity.class);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
app.startActivity(intent);

When the final activity finishes, the Codename One form that opened it returns. You can build new navigation in Codename One while keeping an imported screen for settings or data entry. Shared application logic can call Codename One APIs directly as you remove dependencies on Android-specific behavior.

Start with one complete user journey. Check its inputs, back navigation and persistence on each target. Then choose the next screen based on product value. The migration can stop at a useful intermediate state.

Find the boundary before it finds you

Import requires the application's source. APK execution and Compose UI are outside this layer.

Parcel is an in-process value container here; it does not reproduce Android IPC or serialization snapshots. SQLite uses one connection, so concurrent database work needs care. Reflection-based class loading cannot be carried onto iOS. MotionLayout and CoordinatorLayout are outside the supported surface, and some Material details differ.

Those are reasons to read the limitations, not reasons to rewrite every supported screen. The gallery and port tests give you concrete starting coverage. Your dependencies and workflows determine the rest. The implementation is in PR #5941.

More This Week

Easy Full Stack Authentication and Login in the Style of Spring

Last week's native backend gave us the application structure. This week adds a security stack that connects server access rules to the app making the requests. It includes form login, JWT resource servers and OAuth, with MFA and passkey support for applications that need them.

If you have used Spring Security, the configuration will look familiar. This excerpt from the security example defines a stateless API and requires a scope for reading orders:

@Bean
@Order(1)
SecurityFilterChain api(HttpSecurity http) {
    http.securityMatcher("/api/**")
        .authorizeHttpRequests(auth -> auth
            .requestMatchers("/api/orders/**").hasAuthority("SCOPE_orders:read")
            .anyRequest().authenticated())
        .sessionManagement(session ->
            session.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
        .oauth2ResourceServer(oauth2 -> oauth2.jwt(Customizer.withDefaults()));
    return http.build();
}

On the client, OidcRequestAuthorizer attaches credentials to requests for your API and coordinates token renewal. If several requests need a fresh token at once, they wait for one refresh exchange. A rejected refresh clears the session and returns control to your sign-in UI.

We test that connection end to end. One test supplies an invalid access token, checks that renewal recovers the request, then tries to reuse a spent refresh token and expects the session to end. The client networking code and backend both participate. Browser credentials and redirects have separate test boundaries, which Saturday's article explains alongside the native port coverage.

Saturday's authentication deep dive covers the client setup, persistent server stores and failure cases. The backend security guide and client identity guide have the configuration details.

Update DB Schema in Production with Flyway like Syntax

The backend's security stores need database tables, and those tables need to evolve after deployment. Your app has the same problem: a customer who skips three releases still needs the right local database when they return.

We now have a shared migration engine for the client and server, using familiar Flyway-style filenames. Keep the original schema in V1__create_note.sql, then add a new file for the next change:

-- V2__add_note_created.sql
ALTER TABLE note ADD COLUMN created BIGINT;
UPDATE note SET created = 0 WHERE created IS NULL;

On the client, put these files in common/src/main/db/migration and call Migrations.migrate(db) after opening the database. The annotation ORM does that when it opens the entity manager. On the server, scripts go in the backend module's src/main/resources/db/migration and run before the application accepts requests.

History and checksums let the engine detect changed scripts. Repeatable migrations handle objects such as views, and a database newer than the application is refused before old code changes its data. For servers, a database lock coordinates instances that start together.

Sunday's database migration article covers baselines, skipped releases and recovery after a failed migration. It also explains why a MySQL schema change and a transactional PostgreSQL migration need different recovery plans. The server migration reference includes Maven commands for inspecting and validating history before deployment.

How Do You Test Spring Compatibility?

The Codename One backend uses Spring-style syntax to ease porting, but it is not Spring compatible. How do you know whether the port behaves like the original? Write tests in your Spring application first, then run the same requests and assertions against the Codename One implementation.

The backend now includes @BackendTest, dependency injection and a MockMvc API for carrying those checks across. Change the framework imports and test setup while keeping the behavior you expect. In both applications, the request assertion can look like this:

@Autowired
private MockMvc mvc;

@Test
void greetsByName() throws Exception {
    mvc.perform(get("/greet/{name}", "Ada"))
            .andExpect(status().isOk())
            .andExpect(jsonPath("$.greeting").value("Hello, Ada"));
}

Run it in Spring before the port, then in Codename One after adapting the test setup. A changed status or response is something to investigate, not a reason to rewrite the expected value. Add denied requests and state-changing operations so the suite covers more than the successful response. TestRestTemplate can also cross a real HTTP connection when transport behavior is part of the contract.

The next step is running the tests against compiled native code. The build generates direct test calls and produces reports beside the JVM results. Strict mode makes unsupported test cases fail rather than disappear into a green run. Mockito remains a JVM option; explicit test implementations can run in both environments.

Monday's testing article starts with the Spring test, shows the Codename One changes and finishes with local native test commands. The testing guide documents the supported APIs and the setup for an existing backend module.

Try Real Java in Your Browser, Compiler Errors Included

The Playground now compiles Java as you type. We replaced BeanShell with our Java compiler and the ParparVM translator, both running inside the browser. Source becomes bytecode, the translator produces JavaScript, and the preview loads the new classes. Your source stays in the page.

That means records and lambdas go through actual type checking. Here is part of the example in Tuesday's post:

record Item(String name, int count) {}

Item item = new Item("Orders", 3);
Label label = new Label(item.name() + ": " + item.count());

Change 3 to "three" and the compiler points to the constructor mismatch. Fix it and the preview can run again. The screenshot below shows that deliberate mistake in the public Playground:

The rebuild also removes 161 generated BeanShell adapter source files, totaling about 23.8 MB. That is removed source code, not a browser download measurement. Incremental translation emits the new user classes without rebuilding the entire host application.

Tuesday's Playground article gives you the full interactive example and explains how a Java compiler can run inside its own translated output. You can try it now.

PGO for Faster Apps and Generational/Adaptive GC

Profile-guided optimization (PGO) is now available on Pro and Enterprise cloud builds. The build service runs your application, records which code executes, then compiles it again using that profile. The compiler can make better decisions about inlining, branch layout and where to place frequently used functions. Your users get the optimized native binary.

This works for iOS, native macOS and native Linux. The profile applies to translated Java, the Codename One runtime and your native sources. For an iOS build, enable it in codenameone_settings.properties:

codename1.arg.ios.pgo=true
codename1.arg.pgo.trainingSeconds=90

The service handles both compilations and the training run. If you already have Pro or Enterprise, you can enable it in your next supported cloud build. If you are choosing a plan, PGO is now another reason to look at Pro: the build service can optimize using execution data from your own app.

Training is unattended, so the best candidates do representative work from a clean launch. Code behind a login or button may never be reached. Wednesday's article shows how the training works and how to compare the result against your ordinary build.

ParparVM now switches between concurrent collection and a generational phase when allocation behavior makes that worthwhile. If almost every new object dies quickly, resetting young pages avoids tracing and sweeping those objects individually. The collector can spend less CPU keeping track of garbage.

Giving that phase more memory can reduce collection frequency. It can also make the next full collection worse. During development, one bad transition retained enough young objects to push a stress test's page count from 3,446 to 10,538. Deciding when to leave the generational phase mattered as much as deciding when to enter it. Low available memory now sends the collector back to the concurrent path.

Historical allocation-workload calibration ratios, with JDK 25 equal to 1. Lower is better. These are gate records, not a new controlled benchmark.

The macOS record shows the trade clearly: its time ratio falls from 3.696 to 1.106, while its peak memory ratio rises from 0.481 to 0.937. That is a substantial CPU improvement with a substantial memory cost. It also explains why our performance gate tracks both metrics across its five desktop and server OS/architecture combinations. Mobile and browser behavior have separate port coverage.

These GC records use no PGO. They measure separate runtime work that benefits ordinary builds too. Wednesday's PGO and adaptive GC article leads with the premium build feature, then explores the collector's memory budget, transition failures and regression gate.

Smaller Simpler Maven Projects

Last week we introduced minimal Gradle projects. Maven now gets the same treatment, and the smaller layout is the default for new apps. You start with two POMs:

my-app/
    pom.xml
    common/
        pom.xml
        codenameone_settings.properties
        src/main/java/
        src/main/resources/

The simulator and platform builds still work from that project. Native implementations can live in directories such as ios/src/main/objectivec without needing another Maven module. Add a platform POM when you need separate dependencies or build configuration for that target.

The archetype can generate selected platform modules, all of them, or none. It also has app-with-backend and backend-only project types, so a standalone server does not need an empty client module next to it. Existing projects keep their structure.

Thursday's Maven article shows the commands, native source locations and optional layouts. The archetype reference has the configuration details.

Final Word

This week marks a major milestone for Codename One. For years, we ran on Android. Now we have flipped the script: Android runs on Codename One. The same application can reach iOS, the web and desktop, and its next version can grow beyond the Android APIs it started with. A lot more is coming in this area.

The backend has made a major leap since last week too. With full stack authentication, database migrations and Spring-style testing in place, we now have a substantial backend implementation nearing beta. You can build the client and server together, then test the connection between them with the same tools you use to build the applications.

Discussion

Which screen would you move first if your Android app could reach iOS or the browser before the rewrite was finished?

Don't Order Fish on Monday. Don't Release on Friday

Shai Almog — Thu, 15 Oct 2026 17:45:58 +0000

Anthony Bourdain's famous warning about Monday fish was a warning about the supply chain behind the menu. In his 1999 essay, he described seafood bought for the weekend still being served on Monday. Knowing how the kitchen worked changed what he would order.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

Developers have a similar rule: never release on Friday. If something breaks, you have just made plans for everyone's weekend. It is excellent advice that we have ignored for years.

We settled on Friday releases to avoid dropping a framework update into the middle of our customers' release week. The idea was to use the quieter window to test and repair our release before it collided with theirs. That assumes a lot about when other people ship. It has also cost me plenty of weekends.

This time the problems consumed much of the week. There were regressions around the optional Xcode 27 path, push, and windows. Some overlapped, so a fix could make the original symptom disappear while the underlying problem resurfaced elsewhere. That is exhausting for us, and it is worse for the customer trying to finish an app.

Catch a rejection your device tests can miss

One failure was especially instructive. Apps using particular crypto APIs could compile, link and run, then fail App Store Connect submission because the binary imported non-public symbols. Most apps did not enable the affected code, so most users and our usual tests never encountered it:

_CCCryptorGCMAddAAD
_CCCryptorGCMAddIV
_CCCryptorGCMFinal

The SDK's libraries exported these symbols. The linker could resolve them. But they were not declared in the public headers. A successful link did not establish that they were public APIs suitable for submission.

Our tests had another blind spot: the calls sat behind an optional feature gate that the sample app did not normally enable. Testing the same sample more often would not make that branch appear.

The new checker source preserves the rejection and the causal chain. It is a more useful record than a claim that we “added more tests.”

How your build could enable a feature you never requested

The builder enabled a feature by replacing a preprocessor definition. A plain string replacement for one name also matched the start of a longer name:

#define CN1_INCLUDE_CRYPTO
#define CN1_INCLUDE_CRYPTO_GCM

Enabling general crypto could therefore enable the GCM path too. The customer did not have to request that optional path to compile its imports.

The fix makes the builder match the whole definition name. A focused regression test guards that behavior. The GCM implementation itself was rewritten using public CommonCrypto operations and a C implementation of GHASH, the authentication calculation. The authenticated-decryption path verifies the tag before releasing decrypted output.

A separate sweep found sqlite3_key and sqlite3_rekey imports that were valid for the bundled cipher engine but not public declarations in Apple's SQLite headers. Those imports now depend on the bundled engine defining them. One rejected upload exposed more than one place where “the symbol links” had stood in for “the symbol is public.”

How we will catch this class of failure before it reaches you

A regression test for the three names would catch those three names returning. We also need a check for the broader mistake: importing an SDK symbol that has no public declaration.

The new gate asks that question in two ways:

Check	What it sees	Why it is needed
Source mode	Native port sources with feature gates enabled and optional-engine variants	The ordinary sample does not exercise every feature combination
Binary mode	Imports in a linked Release device app and the covered bundled components	The final link can contain code beyond the port source sweep

The checker uses SDK export information to identify the library symbols and scans public headers with comments removed. A name mentioned in a comment is not accepted as a declaration. It also exercises known private and public controls before trusting a clean result. A check that can never report a failure is a very comforting way to learn nothing.

For a local inspection of a linked app, the script exposes a binary mode:

python3 scripts/check-ios-private-api.py \
  --binary /path/to/Release-iphoneos/MyApp.app --sdk iphoneos

Replace the example path with your Release device artifact; use --developer-dir if the SDK belongs to a different Xcode installation. The repository wires source mode and Release binary mode into its iOS checks. PR #5923 contains the implementation and the builder repair.

Know what your submission check covers

This is an imported-symbol check for the covered C and Objective-C surface. It skips Swift and C++ mangled names that cannot be matched by this header scan, and it does not inspect private Objective-C selectors. The binary check in the repository runs against the covered sample and bundled components, not every arbitrary dependency a customer might add.

It also cannot predict every App Store review decision. Entitlements, privacy declarations and application behavior are different questions. Checking imports catches one specific reason for rejection before you upload.

Review those remaining checks separately when preparing your submission.

We owe you more reliable releases

This week was hard. I spent too much of it chasing regressions, and some of you spent time proving to us that a fix had not really fixed your problem. That is time you should have been able to spend on your own apps. Our release process needs to do better.

Changing the day we ship would not repair the gaps that let these failures through. Our plan is to strengthen the gates around the things we deliver: exercise optional configurations, check the final artifacts, and test rules that cover a whole class of mistakes. We still need the small regression test for each bug. We also need to ask why that bug could reach a customer while the checks were green.

The private API gate is one concrete step in that plan. It checks feature combinations our regular sample missed, examines a linked Release app, and uses known control symbols to verify that the checker can actually fail. The wider work is ongoing; one new gate does not solve every regression involving Xcode, push, or windows.

I cannot promise next week will be quiet. I can promise that a difficult week should leave us with stronger release checks, not just a longer list of closed bugs. As that coverage grows, fewer failures should depend on a customer finding the right combination of APIs for us.

This closes the weekly series. I am excited about the backend and the UI improvements, but you should be able to try them without wondering what else an update will break. That is the release quality we need to earn.

Do You Want Your Web App to Feel Like a Native App?

Shai Almog — Wed, 14 Oct 2026 17:59:45 +0000

You can give your Codename One web app the same desktop theme family as your users' operating system: Aqua on macOS, Fluent on Windows, or Adwaita on Linux. Menus can sit above the app in HTML, with commands such as File and View visible instead of tucked into a mobile overflow menu.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

That gives you a browser version of your app that fits more comfortably on a desktop. The JavaScript port now supports both choices, and the same theme work reaches the Certificate Wizard you use to sign your apps.

Follow the operating system, or choose a theme

Set these in the Settings app's Build Hints:

nativeTheme=native
javascript.titleBar=html

In codenameone_settings.properties, use codename1.arg.nativeTheme and codename1.arg.javascript.titleBar instead. Desktop browsers select Fluent for Windows, Aqua for macOS, and Adwaita for Linux and the remaining desktop systems. Phones and tablets keep the mobile theme selection. The browser detection treats an iPad as a tablet even when it reports a Mac browser.

These are Codename One themes drawing the controls. They are not the operating system's native widget toolkit embedded in the page.

The Settings app demonstrates the three desktop theme families now available to browser apps. Click to compare the controls at full size.

You can pin a desktop theme when the application's design calls for it:

javascript.desktopTheme=fluent

The other explicit choices are aqua, adwaita and none. none keeps mobile themes on desktop browsers. Leave the value at auto to follow the operating system. The broader nativeTheme=modern setting has different behavior: it selects the modern mobile families, including on desktop browsers. Use native when desktop family selection is what you want.

Put commands above the app

The default javascript.titleBar=toolbar keeps the themed Toolbar inside the app. With html, the page supplies title and menu bars instead. The title follows the current form; commands group into menus using the same Command.setDesktopMenu() hint used on the desktop ports.

For example, inside an initialized app:

com.codename1.ui.Form form = new com.codename1.ui.Form("Notes");
com.codename1.ui.Command refresh = new com.codename1.ui.Command("Refresh") {
    public void actionPerformed(com.codename1.ui.events.ActionEvent event) {
        form.setTitle("Notes refreshed");
    }
};
refresh.setDesktopMenu("View");
form.getToolbar().addCommandToOverflowMenu(refresh);
form.show();

Commands without a menu hint go into a Commands menu. The HTML bars follow the selected appearance and the browser's light or dark preference. They do not have fake minimize, maximize or close buttons: the page does not own the browser window. The browser tab title remains the application's display name.

The source is in JavaScriptDesktopChrome, with build-hint and page behavior documented in the JavaScript guide.

Keep navigation inside your browser app

We do not support additional native Window surfaces in the JavaScript port. Popup blockers and the browser's window ownership make that a different promise from drawing a menu inside the current page. Windows browsers are supported; extra OS windows are the unsupported feature. Dialogs and navigation within the app remain the appropriate model.

There are renderer limits too. For example, the full lifted-lens optics from Sunday's iOS article are not implemented in the browser. Try the actual controls and effects your app uses rather than assuming a theme name proves complete renderer parity.

The build prunes theme resources it can prove the app will not reach. If your code constructs resource names dynamically, set javascript.pruneThemes=false; otherwise a theme loaded only through that constructed name may be missing.

Use the same desktop styling when you sign your app

A gallery of buttons cannot tell us whether an application works comfortably with a desktop theme. The Certificate Wizard has longer forms, tables, dialogs and instructions that people must actually read to finish a task.

PR #5916 adopts the native desktop themes there, continuing the work we did in Settings. Its current source uses @DesktopBuild(themeMode = "native", titleBar = DesktopTitleBar.NATIVE, ...), with interactive scrollbars. Fluent, Aqua and Adwaita now provide the surrounding control styles instead of a separate wizard-specific desktop imitation.

The same change fixes handling of an App ID's team prefix. That is a separate functional repair, not a consequence of adopting a theme. The wizard's current source keeps both changes visible.

Try the browser theme with a form that has real commands and enough content to scroll. Switch appearances, open its menus and check keyboard navigation. That will teach you more than another screenshot of an isolated button.

The weekly overview links the rest of the release. It also includes this week's smaller map-label improvement.

Connect Your App to Your Enterprise Traces

Shai Almog — Tue, 13 Oct 2026 19:51:36 +0000

Your customer taps “Place order.” The request crosses your app, an API gateway, a native backend, a payment service and a database. Your operations team needs to see that path in the same tracing system it uses for the rest of the company. Neither the client app nor a compiled Java server should disappear from that picture.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

I wrote a book on debugging, so I am probably more opinionated about this than most people: in 2026, production diagnosis should not depend on somebody searching a pile of logs with grep and guessing which lines belong together.

Logs still matter. At enterprise scale, though, you need to connect work across machines, teams and runtimes, then see whether a failure is isolated or spreading. On a JVM, Java agents can instrument much of that work for us. Once our backend is translated to C and compiled into a native executable, the usual JVM instrumentation hook is gone.

We have to carry that visibility into the binary. OpenTelemetry support started that work last week. The expanded backend API adds metrics and management alongside it. This article follows what happens after you turn them on.

Follow an operation across your systems

Observability is the ability to understand a system's internal behavior from the evidence it emits. OpenTelemetry, usually shortened to OTel, defines APIs, data conventions and transport for producing that evidence. It is not itself the screen where you investigate an incident; a collector and an observability backend handle that part. The OTel primer provides the broader model.

Question	Useful evidence
Why did this request take two seconds?	A trace connecting its operations
Is database waiting increasing across the service?	Metrics over time
What did the application decide at the failure?	Logs and events with context

A span records one timed operation. Related spans form a trace. Metrics aggregate behavior across operations: a count, a current value or a distribution such as request duration. Neither replaces the other. A single trace can explain a slow query without telling you how often it occurs.

Our integration exports traces and metrics. It does not turn every application log into an OTLP log record.

Add tracing to your native executable

Put this in the backend's application.properties before building:

cn1.otel.enabled=true

Or use the backend's @OpenTelemetry annotation. The generator installs the tracer, making its implementation reachable to the translator. Without that build-time opt-in, the unused tracing code can be left out. Setting an environment variable after deploying a binary that omitted the tracer cannot add it back.

Once enabled, the runtime records an incoming request span named for its route template. A Web call creates a client span and propagates W3C trace headers. A database statement creates another client span. Incoming traceparent connects the request to its caller.

The native backend propagates context on outbound Web calls. Each receiving service must accept and continue that context. OTel-compatible instrumentation lets those services participate regardless of their implementation language.

Include the client, not just the servers

The client annotation belongs on your app's main class:

import com.codename1.annotations.OpenTelemetry;
import com.codename1.system.Lifecycle;

@OpenTelemetry(
        relay = "https://api.example.com",
        relayToken = "replace-with-your-relay-token",
        serviceName = "orders-app",
        sampleRatio = 0.2,
        requireAnalyticsConsent = true)
public class OrdersApp extends Lifecycle {
}

Replace the URL with your backend and the token placeholder with your relay token. Set the backend's RELAY_TOKEN environment variable to that same value. Enable its relay as shown below, and wire the app's analytics-consent flow before collecting telemetry. The client instruments supported app operations and ConnectionRequest calls, including outgoing trace context. It sends its recorded spans through the backend rather than carrying your collector credentials.

For browser apps, context propagation is limited to the relay host and configured propagateTo hosts. A cross-origin service must allow the tracing headers in CORS. The client tracing walkthrough covers consent, propagation and the supported span types.

That connects the experience on the device to the work behind it. A server-only trace cannot show the client work before the request or after the response. You can investigate that larger path in your enterprise tracing system instead of keeping a separate, disconnected account of what the app did.

Database spans record SQL as supplied, with placeholders intact; bound parameters are not recorded. If an application concatenates a secret into SQL, the resulting text already contains it. cn1.otel.attributes.exclude=db.query.text can exclude that attribute. Parameterized SQL remains the better habit.

WebSocket lifetime is outside this automatic request-span model. An hours-long connection with thousands of messages is not one useful HTTP request duration, and its upgrade is handled before this tracing path.

Send it to the system your team already uses

For an enabled build, configure a collector at runtime:

export OTEL_SERVICE_NAME=orders-native
export OTEL_EXPORTER_OTLP_ENDPOINT=http://127.0.0.1:4318
export OTEL_TRACES_SAMPLER=parentbased_traceidratio
export OTEL_TRACES_SAMPLER_ARG=0.1
./build/Orders

Here Orders is the packaged application's executable. The ratio samples a tenth of newly rooted traces; the parent-based policy respects an upstream sampling decision.

The exporter uses OTLP over HTTP, with protobuf by default and JSON as an option. It does not implement OTLP/gRPC. It appends /v1/traces or /v1/metrics to the base endpoint unless you supply a signal-specific endpoint.

Dynatrace can receive that OTLP data. For traces, its documented ingest endpoint is configured through OTEL_EXPORTER_OTLP_TRACES_ENDPOINT, with an ingest credential in OTEL_EXPORTER_OTLP_HEADERS. This uses explicit telemetry export; the translated server no longer has the JVM hooks used by Java instrumentation agents.

A dedicated exporter thread batches spans. If the collector is slow or unavailable, request handling does not wait indefinitely for it. A bounded queue eventually drops spans and records the drops. That preserves the service at the cost of incomplete telemetry, which is itself a condition to monitor.

Track latency without a metric for every URL

The server records request duration, active requests, open connections, database pool counts and task queue depth. Scheduled jobs report duration and outcome. The default metric export interval is one minute, using cumulative temporality.

Route labels use /orders/{id}, not /orders/81379. Putting each order ID into a metric label would create a new time series for every order. Templates keep the series count bounded by the API's shape.

The application can instrument a method too:

package example;

import com.codename1.backend.annotations.Counted;
import com.codename1.backend.annotations.Component;
import com.codename1.backend.annotations.Timed;

@Component
public class QuoteService {
    @Timed
    @Counted
    public int quoteCents(int quantity) {
        if (quantity < 1) {
            throw new IllegalArgumentException("quantity must be positive");
        }
        return quantity * 250;
    }
}

This deliberately small example creates a duration histogram and call counters, including a failure counter. The default instrument names derive from the class and method. The build weaves the measurement into the method, so a call through this is measured too. For a real quote service, validate upper bounds and apply the application's monetary rules.

@ManagedResource, @ManagedAttribute and @ManagedOperation offer a JMX-inspired model for current values and operator actions. Numeric managed getters become gauges. The management transport is the backend's own HTTP API; this is not a JVM JMX server hidden inside the native executable. Follow the management configuration before exposing operational actions.

Let an agent check the running application

MCP, the Model Context Protocol, gives a development tool a structured way to ask the server questions. The backend serves tools for listing routes, inspecting beans, reading recent requests and querying the database. After editing a handler, you can call it and inspect the row it wrote from your development tool.

A practical loop is:

Start the backend on its development profile.
Inspect backend_routes, backend_beans and backend_schema.
Make the edit, then stop and restart the server. There is no hot reload.
Exercise the handler with backend_call.
Check backend_requests, backend_sql and backend_metrics.

The default SQL tool uses a database-enforced read-only transaction unless its caller explicitly requests write access. An application can publish its own methods with @McpTool; the build derives JSON Schema from their supported parameter types and calls them directly.

For a tool of your own, here is a complete bean using the generated dispatch:

package example;

import com.codename1.backend.annotations.McpParam;
import com.codename1.backend.annotations.McpTool;
import com.codename1.backend.annotations.Component;

@Component
public class QuoteTools {
    private final QuoteService quotes;

    public QuoteTools(QuoteService quotes) {
        this.quotes = quotes;
    }

    @McpTool(description = "Returns a quote in cents for a positive quantity.")
    public int quote(@McpParam("quantity") int quantity) {
        return quotes.quoteCents(quantity);
    }
}

It reuses QuoteService above. The description tells an agent when the tool is relevant, and @McpParam supplies a stable argument name independent of compiler parameter metadata. Runtime authentication still has to be configured before serving it outside development.

Development tools are omitted by backendPackage / cn1:backend-package unless deliberately enabled. Outside development, the MCP endpoint requires a bearer token. A tokenless development server is restricted to loopback. Origin checks also matter when a browser can reach that machine. The MCP chapter spells out these boundaries.

Keep collector credentials off the phone

An app can send its own spans through the backend relay. The relay validates the OTLP/JSON payload, applies size and span-count limits, then queues it for export using credentials held by the server.

cn1.otel.relay=true
cn1.otel.relay.token=${RELAY_TOKEN}
cn1.otel.relay.corsOrigin=https://app.example.com

The relay requires the client's relayToken to match RELAY_TOKEN; a missing or different token returns HTTP 401. The CORS setting is for a web app on another origin. An app-carried relay token is not an unextractable secret; the collector's ingest credentials should remain on the backend. A full queue returns 503 so the client can back off.

Start with one real app action that crosses the native backend and an existing enterprise service. Verify that its spans share a trace ID in your collector, then check consent, sampling, queue drops and access to the relay before expanding collection. The goal is to make the app and its native server observable parts of the system your operations team already runs.

Do You Prefer Gradle?

Shai Almog — Mon, 12 Oct 2026 21:43:37 +0000

You can now choose Gradle for a Codename One project. Start with fewer files, add platform directories when you need native code, or create a standalone backend without a mobile app attached. A smaller project is easier to browse and leaves less scaffolding competing for space in an LLM's context.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

I like Maven XML. I know it is verbose. I also spent enough time at Sun Microsystems staring at deeply scripted, heavily patched make files to develop a lasting suspicion of clever build systems.

Someone starts with a reasonable shortcut. Someone else needs one more condition. A few years later the build has its own undocumented programming language and nobody wants to touch it. I would rather a build system be strict and limited. Give people enough power and, with the best intentions, they build a Frankenstein build.

That is a personal preference. Plenty of developers I respect love Gradle, or at least appreciate what it lets them do. This week we added optional Gradle support because it lets us offer something useful: a smaller Codename One project, including a standalone backend with no client scaffolding.

Start with fewer files

The Maven app layout has a root POM and platform modules ready for native code. That makes the structure explicit, but a new app often has no code in most of those places.

A Gradle app starts with the sources and configuration it needs. Native directories appear when you generate native interfaces. A backend subproject appears when you add a backend.

For a concrete example, we converted the checked-in HelloCodenameOne sample with the current converter:

Project files	Maven sample	Converted Gradle sample
Total files, including app sources and resources	358	305
Maven POMs	9	0
Gradle Kotlin configuration files	0	2

That removes 53 files, about 15% of the tree. We counted the tracked sample before conversion and all files in the converter's new directory afterward, excluding build output and caches. This is the existing demonstration app, with its resources and Kotlin source, rather than a comparison of two different Hello World programs.

The generated settings.gradle.kts is small enough to show in full, with its explanatory comments removed:

pluginManagement {
    repositories {
        maven("https://repo.codenameone.com/maven2")
        gradlePluginPortal()
    }
}
plugins {
    id("com.codenameone") version "7.0.274"
}
rootProject.name = "HelloCodenameOne"

The example selects release 7.0.274, which includes Gradle support. The app's own dependencies and Kotlin plugin go in build.gradle.kts; the framework's platform builders come from the Codename One plugin.

MyApp/
  settings.gradle.kts
  gradle.properties
  gradlew
  gradle/wrapper/
  codenameone_settings.properties
  icon.png
  src/main/java/
  src/main/css/theme.css
  src/main/resources/

Add build.gradle.kts when you have dependencies or build configuration of your own. Kotlin source belongs in src/main/kotlin when the project applies the Kotlin plugin.

That smaller tree helps a human understand an unfamiliar project. It can also reduce the irrelevant files an agent sees when building its context. The file reduction is measurable; the context saved depends on which files your agent reads.

Keep the same builds when you switch

We did not implement a second set of platform builders. The Gradle plugin calls the shared engine used by Maven. That includes upload staging, local builders, CSS compilation and bytecode compliance checks.

From a generated Gradle app:

./gradlew run
./gradlew cn1Test
./gradlew buildJavascriptLocal
./gradlew buildIosXcodeProject -Popen=false

run starts the simulator. cn1Test uses the simulator test runner. The last two commands build the JavaScript port locally and generate an Xcode project. Tasks that submit cloud builds are available too, with the same service requirements as Maven.

There are limits. Running Gradle requires JDK 17 or newer and Gradle 8.5 or newer; the generated wrapper supplies Gradle. These projects target Java 17. They do not support legacy .cn1lib files or the old resource Designer task. The OpenAPI, gRPC and GraphQL generators and on-device debugging helpers still have Maven goals without equivalent Gradle tasks. The workflow chapter lists the supported surface.

Build a standalone Java backend

In the Initializr, choose Gradle as the build tool and Backend only as the project type. The server lives at the root, with its Java source and application properties. There is no client theme, simulator module or collection of empty native directories.

For a generated project named MyService:

CN1_PROFILE=dev ./gradlew runBackend

That runs the development server on the JVM. Stop it before changing the backend code; this is a restart workflow, not hot reload. To build and run the native executable:

./gradlew backendPackage
CN1_PROFILE=dev PORT=9000 ./build/MyService

The development profile uses the generated in-memory SQLite configuration. Without it, the starter reads its production settings and expects DATABASE_URL. The executable's name follows the project name.

An existing Gradle app can gain a server with:

./gradlew addBackend
CN1_PROFILE=dev ./gradlew :backend:runBackend
./gradlew :backend:backendPackage

I hope people will try the backend on its own. It is still experimental, but a small independent service can reveal useful constraints without requiring a mobile application first. The weekly overview shows the Spring-style programming model it now supports.

Try Gradle alongside your Maven project

The converter leaves the original project in place and writes a sibling project. Replace VERSION with the Codename One plugin release containing this feature:

mvn com.codenameone:codenameone-maven-plugin:VERSION:convert-to-gradle \
  -Dcn1.sourceProject=/path/to/MyApp \
  -Dcn1.outputDir=/path/to/MyApp-gradle

The destination must be empty or absent. The conversion carries sources, resources, CSS and platform implementations into the new layout, and raises the application's bytecode target to Java 17. A customized backend comes across; the untouched backend skeleton is optional. Legacy .cn1lib dependencies stop conversion with their names rather than silently disappearing.

Open the converted project and run its tests before switching the team's build. Your old checkout remains available for comparison.

Find the API for the code you are writing

Last week we split the Developer Guide into chapters. Before that, we rebuilt the Javadocs. A backend-only project made the next problem obvious: a client API page is the wrong answer when you are writing a server.

PR #5918 separates the client API from the backend API. The references label their audience and link shared classes to their counterpart. Backend classes belong in the backend reference; a UI implementation package does not belong there just because it exists in the repository.

What you are writing	Reference to start with
A form, component or device integration	Client Javadocs
A controller, database service or scheduled job	Backend Javadocs
Shared models and mapping code	The shared class page, with its counterpart link

The distinction helps readers and code-generation tools for the same reason: it reduces the chance of choosing an API that exists in the wrong runtime. Both references are checked with doclint, so malformed documentation has a build-time consequence too.

Try Gradle 9 for your Android build

The optional Gradle project layout and the Gradle version used inside a generated Android project are different choices. You can keep your Codename One app on Maven and still test the newer Android builder.

In Settings, under Build Hints:

android.gradleVersion=9

Or in codenameone_settings.properties:

codename1.arg.android.gradleVersion=9

The current builder pairs Gradle 9.8.0 with Android Gradle Plugin 9.4.1. It adjusts the generated project for removed DSL elements and AGP's built-in Kotlin support. This selects the experimental Gradle 9 / Android Gradle Plugin 9 path from PR #5919. It is opt-in. Much of the surrounding tooling and library configuration still assumes Gradle 8. Test your actual native dependencies and generated Android project before adopting it; a successful empty app is not the same test.

I expect to keep using Maven for plenty of projects. Supporting Gradle gives teams another way into the same build machinery, and gives a small server a project tree that looks like a small server.

Can You Tell the Difference Between These iOS Tab Bars?

Shai Almog — Sun, 11 Oct 2026 18:18:59 +0000

Watch how the two tab bars respond to the recorded taps, holds, drags and changes of direction. Can you tell which one is UIKit and which one is drawn by Codename One?

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

That is a more useful test than a still image. Your users feel the delay before a selection moves, the way the glass follows a finger and the settling motion after release. A tab bar can have the right colors and still feel wrong in your hand.

Last week's iOS 27 theme was close, but I still wasn't happy with those interactions. Getting closer meant recording UIKit's presentation layers during real touches, fitting the motion to spring equations and reconstructing the glass effects. Here is the result, followed by the measurements and formulas behind it.

Watch the same gestures twice

Download the light comparison video.

UIKit is on top and Codename One below. These committed iOS 27 simulator recordings use the same touch sequence: six taps, a held press, a tap on the selected tab, a slow drag and a flick. Each gesture occupies a 4.2-second slot aligned on the touch.

Download the dark comparison video.

The dark appearance exposes the edge, vibrancy and refraction differences more clearly. UIKit is above Codename One in both simulator recordings.

The recording script and video notes make the provenance inspectable. The remaining differences are part of the comparison: the lifted lens, its rounded ends and the saturation still deserve work.

Why your tab bar can look right and feel wrong

Setting the selected tab in code did not produce the complete native interaction. UIKit performs that motion for genuine touches on a controller-managed bar. The probe therefore uses XCUITest taps, holds, and drags.

There was another complication: UIKit did not attach a simple CAAnimation containing the whole trajectory. It updated layer values frame by frame. The useful record was the presentation geometry at each display refresh: position, bounds, transform, opacity and the touch timestamps that explained them.

Capturing an image on every frame changes the timing enough to contaminate the measurement. The probe separates geometry logging from optional frame snapshots. Snapshot runs are useful for comparing the lens at the same motion state, not for fitting its timing. Likewise, lossless screenshots over known backdrops reveal the blur; compressed video smears the very edges we need to inspect.

Those constraints are documented in the native probe. They explain why “looks close in a recording” was not enough.

Make taps, holds and drags respond differently

For a fixed target, a damped spring follows this equation:

Here x is position, xₜ is the target, ω controls the natural frequency and ζ the damping. Dots denote derivatives with respect to time. A critically damped spring has zeta = 1; lower damping allows an overshoot. The implementation uses the measured constants rather than retuning the entire animation by eye:

Channel	Model in the current source
Selection travel	`omega = 2*pi/0.4`, `zeta = 0.85`
Lens lift	Critical damping, `omega = 2*pi/0.25`
Platter return	Critical damping, `omega = 2*pi/0.4`
Whole-bar press growth	`omega = 17.6`, `zeta = 0.59`
Lens following a drag	`omega = 32`, `zeta = 0.90`

The travel stops once the remaining distance after the overshoot is below about 0.195 points. The drag and press models include a measured 20 ms touch lag. These small details are visible because your finger gives the animation a moving reference point.

The current TabGlassMotion and TabGlassGesture contain the formulas, retained tables and stopping rules. The regeneration tool checks the closed forms against captures and rewrites the channels that remain tabulated.

Let users drag across tabs without selecting each one

During a drag the lens follows the finger on its own spring, so it can lag behind. On release, UIKit selects the tab under the finger, not the one nearest the lagging lens. The lens then settles toward that tab from its current position and velocity.

Resetting velocity at that handoff creates a visible interruption. Snapping to the nearest lens position after a fast flick creates another discontinuity. A press on the already selected tab must also lift and pulse without inventing travel to another tab. A held press has to keep its lifted state until release rather than play a fixed-duration tap and finish underneath your finger.

The release adds a small wobble. Our model uses a common starting point for it even though the captures show slightly different onset times across gesture types. That approximation is one reason to keep the full gesture suite alongside the short demo.

Keep icons legible as the backdrop changes

A vibrant tab icon is not simply painted with an alpha color. Its result depends on the glass behind it. The probe reads UIKit's color matrices across tint sweeps, and VibrancyMatrix reconstructs the transform.

For a non-gray dark tint vector t, the measured form is:

e = 0.5 * min(t) / max(t)
M = e*I + (0.5 - e) * (ones * transpose(t)) / dot(t,t)
offset = t
output = M * backdrop + offset

I is the identity matrix and ones is a column of three ones. Gray tints have their own formula, so this expression is not a universal branch to paste over the implementation. Light appearance uses a different form. The vibrancy source and recorded fixture hold those cases together.

The selection platter also transforms the bar's existing glass. Graphics.colorMatrixRegion applies that operation within a shape and optional mask. The lifted lens needs a separate operation: refraction around a circular bevel, color dispersion, an outline, rim light and shadow. glassLensRegion supplies that rendering path.

This is why adjusting the opacity of a rounded rectangle could only take us so far. The effect changes the content underneath it.

Keep the glass animation on the GPU

A more accurate motion model is wasted if the renderer misses the frames that distinguish it. The iOS bar glass now runs on the GPU instead of passing through a CPU blur with GPU synchronization around it. Mutable images reuse their stencil texture. The tab animation avoids asking for a second whole-component repaint, and the lens scratch texture is released after use.

The portable color-matrix operation reaches the JavaScript port too. The browser lens still lacks the full optics implementation. A shared API does not mean every rendering backend implements every effect today.

Choose the appearance, then test your screen

In the Settings app's Build Hints, select:

ios.themeMode=modern
ios.themeGeneration=27

For the cloud toolchain, ios.xcode_version=27 is a separate setting. In codenameone_settings.properties, prefix build-hint keys with codename1.arg.. A local Xcode build uses the Xcode installation selected on your Mac.

Codename One draws these controls itself. The theme and its motion ship with the app, so adopting this appearance remains your decision. That control also gives us the responsibility to measure the behavior we reproduce.

Try the animation over a photograph, a scrolling list and a plain dark background. Hold it. Drag past the middle and release. The implementation in PR #5906 and the fixtures behind it make those interactions repeatable instead of leaving fidelity to memory.