Skip to content

Ruflet on rails - #26

Merged
AdamMusa merged 76 commits into
mainfrom
ruflet_on_rails
Sep 7, 2026
Merged

AdamMusa merged 76 commits into
mainfrom
ruflet_on_rails

Conversation

@AdamMusa

@AdamMusa AdamMusa commented Sep 7, 2026

Copy link
Copy Markdown
Owner

No description provided.

main and this branch both moved the runtime into the platform layer, so the
autostart files conflicted as parallel implementations rather than as edits.

The branch's in-process transport is the later design and it wins: a packaged
app reaches its runtime over the binary bridge at inprocess://embedded, with no
loopback socket. main's start()-compatibility path mirrored the autostarted
port into the file a legacy client polls; there is no port to mirror here, so
every platform keeps this branch's explicit in_process_runtime_owned error
instead. Clients still calling start() on a self-contained build now fail
loudly rather than hanging on a port that never appears.

The branch already carried main's decoupling fix -- the packaged project is the
opt-in, so autostart no longer depends on the CLI, template and runtime being
published in order -- which is why those hunks merged as parallel text.

Taken from main: the narrowed podspec preserve_paths (Apple only ever includes
desktop/ruflet_vm_host.h, so the desktop-only autostart and bridge headers no
longer ship in the pod), the versioned-client release steps, and the rule that
a control name is never sent as a service argument.

Kept from this branch: the prebuilt VM artifacts. main changed no VM sources at
all, while this branch vendors SQLite and ruflet-record into them, so main's
rebuilt blobs would have silently dropped RufletRecord from the runtime.

The CLI keeps both project pins: the dart-define that main.self.dart reads to
resolve assets/<project>/assets, and configure_platform_autostart, which writes
the same decision into the bundle for the native layer that starts the VM
before Flutter exists. Self-contained builds no longer pass RUFLET_BACKEND_URL,
which is this branch's deliberate removal.

Tests: packages/ruflet, ruflet_core, ruflet_server and ruflet_rails all pass.

Also removes the Swift rendering engine.
--------------------------------------------------------------------------
Apple builds no longer have a second renderer. --experimental / --exp stays,
but it now names a release channel rather than an engine, so every platform
renders through the Ruflet Flutter engine.

Gone from the CLI: NATIVE_APPLE_EXTENSION_MAP and the Swift extension codegen
that wrote RufletEngineChoice.swift, the apple_packages/ruflet_apple template
sync and its distribution check, the apple_extensions scaffolding in
`ruflet new`, the RufletExperimentalNativeRenderer dart-define and plist flag,
and tools/sync_apple_engine.rb. Selected extensions now always ship as their
Flutter plugins; nothing excludes them in favour of Swift equivalents.

What stays is the teardown. A client generated while the renderer existed still
carries apple_packages/, apple_extensions/, RufletEngineChoice.swift, the Xcode
package references and a RufletSceneDelegate entry in Info.plist. Rebuilding
strips all of it and restores the Flutter host, so those projects migrate by
being rebuilt rather than regenerated. That path is unconditional now, and
test_standard_apple_build_removes_native_renderer_integration covers it.

The tests that exercised the renderer are deleted rather than rewritten; the
cache-exclusion fixture in new_command_test moved off the Swift package to a
Dart one, since the behaviour it checks is about generated directory names and
not about Apple at all.
@AdamMusa
AdamMusa merged commit 2e63a3b into main Sep 7, 2026
1 check failed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant