More Connected, More Capable: The September Apex Infinity Update

In our August update, we gave Apex Infinity a clearer front door. Since then, we have been building more of the experience behind it: the app you use, the tools that support you, the hardware being prepared for assembly, and the resources that let other people start exploring the platform.

The work from late August through September 16 reaches across the system. Companion has a new visual identity. The Developer Portal is live. Website visitors have a direct contact path. Core has received firmware and manufacturing refinements, while a new Fleet Manager prototype explores what managing several devices could feel like.

Some of these changes are already deployed. Others are in development or still need hands-on validation. Here is what moved forward, and where the next steps remain.

Companion feels like part of the same platform

The visual direction introduced on the website now carries into Companion. Navy surfaces, blue and cyan accents, a subtle background grid, and more consistent cards bring the app into the same design family. Device cards adapt more naturally to different screen sizes, so the experience feels connected across a desktop and a phone.

We also removed transitions between the main pages after reviewing how they felt in use. Navigation is more direct, with less animation between the places people visit most often. The refreshed interface was reviewed and accepted on Mac and iPhone.

Behind that visible work, we updated the app's account-service connection and worked through Apple platform changes affecting launch behavior, builds, and TestFlight delivery. The release process now distinguishes between tools used for development and those accepted for TestFlight submissions. Updated iOS and Mac builds reached TestFlight and received hands-on acceptance. Shared visual foundations also make it easier for future Apex desktop tools to look familiar.

Device reconnection remains an active area of work. We have been investigating how Companion recovers connections, resumes after interruptions, and handles firmware-update recovery across connected devices. Testing has exposed behavior that still needs attention, so we are keeping that work in validation rather than calling it finished.

Core firmware and hardware move forward together

Core now has an updated, selectable firmware configuration for Revision F, and the corresponding simulator has been brought into alignment. The existing default development configuration remains available. Keeping those development environments consistent helps us investigate behavior against the board we are actually preparing, rather than an earlier design.

We also corrected a diagnostic-download cleanup problem and strengthened how production and provisioning tools handle sensitive files. These are focused changes to make troubleshooting and release preparation more dependable. Their software checks provide useful evidence, while physical-device validation remains a separate step.

For Classic, we adjusted idle behavior while connected to USB so bench work can continue without the same short timeout used on battery. The existing battery timing was preserved. The updated firmware was loaded and its startup checked on hardware; longer timing checks and connection-recovery acceptance remain open.

Alongside the firmware work, Revision F went through further manufacturing review. We corrected component placement, clarified assembly orientation, reconciled the BOM with assembly instructions, and revised solder-mask details in response to supplier questions. The revised handoff packages were checked against their design sources so the intended correction could be distinguished from unrelated changes.

We also reviewed follow-up manufacturing questions and documented the conditions for accepting proposed production methods. Supplier confirmation and validation of the first assembled boards remain necessary. A checked design package is an important milestone, but it does not tell us everything a physical board will.

Early planning also began for a possible Core 2.0 prototype. That work establishes constraints and evaluates the impact of a future design while keeping the current Revision F effort intact. It remains a planning exercise, without a new hardware availability announcement.

A dedicated place for builders

The Apex Infinity Developer Portal is now live.

It gives builders a dedicated starting point for understanding the platform, using an Apex account to enroll for developer access and reach the resources prepared for them. The main website now includes clear entry points to the portal.

One of its most useful additions is Packet Lab. It lets developers explore synthetic examples and scenario presets, making it easier to see how information is represented and how an integration should respond. That creates a practical learning environment before a developer needs to work with a physical device.

We also documented a read-only BLE integration surface and added structured reference material to make it easier to interpret consistently. This is an initial, bounded foundation for outside development. Packet Lab uses simulated information, and the portal does not imply unrestricted device control or a complete general-purpose API.

Sign-in, developer enrollment, protected resources, and the sample scenarios received deployment checks, including signed-in verification. The result is a concrete next step toward the broader builder ecosystem described in our last post.

Fleet Manager takes shape in simulation

Companion focuses on the relationship between a person and their devices. Fleet Manager explores the needs of someone responsible for several devices at once.

We built a desktop prototype around a simulated fleet so we can evaluate its workflows before connecting them to real equipment. It brings device groups and kits, reusable profiles, local Face Studio imports, previews of proposed changes, and individual device results into one workflow. Simulated interruptions let us exercise selective retries and recovery, while saved history keeps the results available after restarting the app.

The visual direction shares the Apex family resemblance while giving Fleet Manager its own orange accents. This also extends the value of existing Face Studio exports without requiring a new Face Studio release.

The prototype has undergone automated checks, a Mac build, and native visual review. Real-device communication, production services, and the remaining operator acceptance checks are separate work. Windows and Linux still need their own native verification.

We have also started defining how future fleet operations should preserve existing preferences, confirm that transferred content is ready, and respect device authorization. Those decisions need to be settled before the prototype becomes a tool that changes real devices.

Support has a clearer path from question to answer

The contact service described in August now has its public website form. Visitors can send product questions, support requests, partnership inquiries, and privacy or account questions through a direct route to the Apex team.

The tools behind that contact path have improved as well. A unified Admin Console brings account support, analytics, beta management, partner management, and access administration into one place.

New account diagnostics help the team recognize possible duplicate sign-in records without automatically changing them. A purchase timeline brings payment, access rights, and library membership into the same view, making it easier to understand why something a person owns might not appear where expected. Administrative access changes also have more explicit controls and records.

We corrected a mobile website sign-in problem and confirmed the revised flow in mobile Safari. A separate improvement to native Apple and Google account handling has been implemented and tested locally, with live-provider and recovery checks still required before release.

Better preparation for beta testers and partners

We added the website and service workflows for invitation-only beta participation: private invitations, agreement review and acceptance, participant status, and manager controls. Signed agreements can be downloaded as complete, paginated PDFs so participants can keep their own copy.

The partner workflow now supports applications, human review, individual benefit schedules, private offers, agreement acceptance, and repeat access to signed records. It gives the team a structured way to prepare Ambassador and Sponsored Athlete relationships instead of managing every step separately.

These are operational foundations, not an announcement of open enrollment. Beta participation remains invitation-only, with program activation and provisional agreements subject to the necessary setup and review. The partner program remains inactive pending readiness and agreement review.

We also tightened private-invitation handling across the website and its supporting services, reducing unnecessary exposure of invitation credentials as people move through those flows.

A website that is easier to use and find

Individual blog posts now have permanent article addresses, and the blog index presents its content in a form that is easier for search engines and other readers to discover. Page descriptions, sharing information, and the public sitemap received a broader review as well.

Keyboard navigation and dialogs were another focus. Account and cart interactions now manage focus more deliberately, support keyboard dismissal, and use clearer accessibility semantics. Automated checks help catch regressions as the site changes.

We continued the visual cleanup across the site, added recognizable browser and home-screen icons, and made sure unavailable downloads remain disabled. Visitors should be able to tell what they can use today without following controls that suggest a release is ready when it is not.

The publishing process also now turns approved drafts into their public versions automatically and checks that those versions agree. That reduces the chance of an edited article and its published copy drifting apart.

Clearer information about privacy and software

The website now includes an interim Privacy Notice, draft Terms, instructions for requesting account deletion, and a security contact. These pages make the current processes easier to find while preserving their review status. Account deletion remains a manual request process; self-service deletion has not been deployed.

We also mapped the information handled across the website and its connected services. That review identified where retention decisions and deletion behavior still need work. It gives the next phase a concrete basis without presenting unfinished controls as completed promises.

For Core firmware, we introduced a more detailed record of the software included in a particular build, its licensing evidence, and the notices that accompany it. Release checks now require that evidence to match the actual build and stop publication when required information is unresolved.

The first reviewed development-build notices are available through the website's Software Notices page. Supporting documentation explains how to find notices for the complete firmware version in use, and the publication process checks that the reviewed files are the ones delivered.

Publishing those notices does not release the firmware itself. Licensing review, security review, device validation, and distribution remain distinct responsibilities. Further work is underway to assess security findings against the components and configuration actually included in each build, with unresolved findings still treated as release blockers.

Stronger checks around the whole experience

The email protections described in our last update have progressed from monitoring into enforcement. That strengthens checks against impersonation and secure-delivery requirements where supported.

Website testing now covers public pages across desktop and mobile browsers, with a separate controlled sign-in check. We tightened how those tests handle credentials so private sign-in material is not retained in diagnostic recordings. Security reviews also produced follow-up work that remains tracked rather than being treated as resolved simply because the review finished.

Across the platform, we extended the planning records that connect new tools to the products and services they depend on. Developer Portal, Fleet Manager, future hardware work, and firmware notices each benefit from checking those relationships before changes are released.

Face Studio, voice content, eyewear, and the other device designs remain part of that wider platform. This period's new work concentrated on Companion, Core, Classic, developer access, manufacturing preparation, and the services around them; it does not introduce a new release for every product.

The next milestones are practical ones: complete the remaining connection and timing checks, close manufacturing review questions, evaluate Fleet Manager's workflows, and carry the new release evidence through future firmware delivery. Each step brings Apex Infinity closer to an experience people can use, understand, and build upon with confidence.