The Work Behind a More Dependable Apex

A good update starts long before a download appears. It starts with knowing what went into the software, checking how it was built, and confirming that the files prepared for delivery are the ones that were reviewed.

Building on our September 16 update, this post takes a closer look at the latest release and validation work across Apex. Core, Classic and Edge now have more complete build records. The voice tools and supporting cloud services have stronger release checks. We also repaired a website publishing problem and worked through another manufacturing question for Core.

Much of this happens behind the scenes. It helps us catch problems earlier, preserve the details needed to investigate them, and make future updates easier to reproduce and support.

Core, Classic and Edge: a record for each build

Our last update introduced Core's software inventory and licensing records. That process now also covers Classic and Edge, with a separate record for each product even where they share software.

Those records connect a particular firmware build to its software components, configuration, development tools and included assets. They also bring together the relevant licenses and notices. Readable summaries sit alongside the structured records used by our release tools, so the evidence can be inspected by people as well as checked automatically.

We have also completed build-specific reviews of the security alerts identified in this work. An alert about a shared library needs to be checked against the code and features a particular product actually uses. We retain the original findings and the reasons for each decision, and the release checks stop when a new or unresolved finding needs attention.

The process follows the files through release preparation, including checking downloaded copies against the reviewed originals. Existing public information is available on our Software Notices page, where notices are tied to the firmware version they describe.

These are improvements to development and release preparation. Physical-device validation remains a separate step.

Keeping Classic and Edge looking like themselves

Rebuilding a display face should reproduce the design we chose. We found that some font-generation steps could select different fonts depending on the computer doing the work.

The source fonts and generation tools are now recorded precisely, and the process rejects unexpected substitutions. We verified that the current digit fonts and analog dial artwork reproduce exactly. The visible designs remain unchanged.

We also fixed a firmware publishing failure on Mac. New checks reproduce the conditions that caused it before longer builds begin.

Shared software and voice tools get the same attention

Core, Classic and Edge depend on common software. We repaired its development build setup, added checks on Mac and Linux, and verified that it can be consumed by the firmware development environment. Its source and licensing records now travel with an exact software revision.

The voice tools now record the inputs and generation tools for new output. We reviewed security findings, applied relevant updates to the generation tools, and strengthened the checks that run before the more expensive work begins.

We also corrected a source of repeated review noise: changes to a daily risk score could reopen an otherwise unchanged assessment. The process now preserves that changing information while distinguishing it from changes that affect the technical decision.

This work preserves the reviewed voice content and audio format. It does not introduce a new voice pack.

A publishing fix visitors can feel

We found and fixed a problem that could publish a new blog page without all the files it needed to load correctly. That could leave a page looking available while failing when opened in a browser.

Publication now places the required supporting files first and keeps older versions available for pages a visitor's browser may still have saved. We verified both complete website publication and blog-only publication, then checked fresh page loading and navigation.

The independent daily browser checks received their own repairs. They now follow the current page controls and distinguish a failed check from a timeout, an intentionally skipped case or a problem with the test environment. The latest daily run passed across all six desktop and mobile browser configurations, with the expected differences between screen sizes recorded separately.

Together, these changes improve both the publishing process and our ability to recognize when the live experience needs attention.

Clearer release records for the services behind Apex

The same approach is now taking shape around the services that support the platform. We added inventories, license records, security scans and retained release evidence for the software packages prepared for those services.

The checks connect the proposed package to its source and planned configuration, and verify that the retained copy can be downloaded intact. Earlier checks also exercise the real tools and command environments used during release preparation, so basic setup failures can be caught before longer builds begin.

This phase established and verified the evidence pipeline. It did not deploy a new version of the cloud services. Next, we need to complete the checks connecting the Developer Portal's build and deployment processes, followed by the remaining app and publishing work.

Another manufacturing question made easier to review

Core's manufacturing preparation also moved forward. We examined a supplier question about the board's radio-signal routing and prepared a controlled set of supporting information and diagrams from the existing design.

That gives the next manufacturing discussion a clearer technical basis while preserving the current board design. The work prepared the material for review; it did not change the design or establish production approval. Supplier confirmation and validation of assembled boards remain later steps.

More checks, with a clear account of what they prove

Across the work reviewed for this update, we verified passing results for 1,576 distinct automated tests. That total includes existing tests and newly added coverage, with repeated browser and platform runs counted once.

The tests cover software behavior, release rules, reporting and build evidence. They help catch regressions and explain failures. They do not replace physical-device testing or turn a prepared cloud package into a verified live deployment.

Software inventories, licensing records and release checks are now part of our documented development requirements across the platform. The next work implements those requirements in the remaining applications and publishing paths, including Companion and Face Studio.

Our aim is to make each future release easier to examine: what changed, what was checked, what is ready, and what still needs validation.