Add native Gutenberg editor package

[chubes4]

Goal

Add first-class native Gutenberg editor support to wp-native, since the project is designed as a WordPress-native mobile app builder rather than a WebView wrapper.

wp-native should provide a reusable framework-level editor package that wraps Gutenberg Mobile's native editor surface and connects it to the existing wp-native-client / Abilities API stack.

Context

wp-native currently provides auth, token lifecycle, navigation, theme, browser handoff, and ability-driven screens. Native authoring is explicitly out of v0.1 scope, but it is a natural framework capability:

• wp-native is a WordPress mobile app framework.
• extrachill-app wants Gutenberg as the in-app authoring surface.
• Gutenberg already has a React Native editor package: @wordpress/react-native-editor from WordPress/gutenberg.
• Blocks Everywhere solved the related web problem by moving off @automattic/isolated-block-editor and onto current Gutenberg primitives. Native should use Gutenberg Mobile's native runtime, not IBE.

Proposed Shape

Create a new package, likely:

packages/editor

Public API candidates:

<WPNativeGutenbergEditor
  loadAbility="extrachill/forum.reply.editor.load"
  saveAbility="extrachill/forum.reply.editor.save"
  mediaAbility="extrachill/media.upload"
  context={{ replyId }}
/>

Or a screen-level wrapper:

<WPNativeEditorScreen
  title="Reply"
  loadAbility="..."
  saveAbility="..."
  mediaAbility="..."
/>

Responsibilities

• Wrap @wordpress/react-native-editor / registerGutenberg() behind a stable wp-native API.
• Integrate with useAuth() and wp-native-client for authenticated ability calls.
• Define generic editor load/save/media/autosave contracts.
• Support initial block content, dirty state, save state, error state, and navigation guards.
• Provide TypeScript types for editor ability inputs/results.
• Keep app-specific ability names in consumer config/screens, not in the framework.
• Document native dependency requirements, including Expo custom dev build constraints.

Non-Goals

• Do not use WebView as the primary editor runtime.
• Do not revive @automattic/isolated-block-editor; that is a web/DOM abstraction and not appropriate for native mobile.
• Do not put Extra Chill-specific routes or API clients into wp-native.

Acceptance Criteria

• wp-native exposes a generic native Gutenberg editor package/surface.
• A consumer app can load editor content through an ability, edit blocks natively, and save through an ability.
• Media upload is represented as a generic ability contract or documented extension point.
• The package works with the existing wp-native-shell auth provider and wp-native-client transport.
• Docs clearly explain how this differs from Blocks Everywhere and why IBE is not used.

[chubes4]

Related stack issues:

• Server editor abilities: Add editor abilities for native Gutenberg authoring Extra-Chill/extrachill-api#58
• App editor screens: Add in-app native Gutenberg editor screens Extra-Chill/extrachill-app#47
• Auth/session verification: Verify auth/session support for native Gutenberg authoring Extra-Chill/extrachill-users#51

[chubes4]

Design investigation — native Gutenberg editor package

Investigation only. No code written, no PR opened. Findings + design proposal per RULES.md "Check what already exists before designing new infrastructure".

This comment is the design deliverable for #46. It is intentionally long because the load-bearing finding below changes the framing of the issue and must be documented before any code is written.

---

TL;DR

1. @wordpress/react-native-editor is not a consumable npm package — it is private: true, file:../*-linked to the Gutenberg monorepo, unmaintained on trunk, broken on React 19 (wp-native requires React 19+), and architected as an AppRegistry-registered root component, not a composable <Editor/> React element.
2. The supporting native bridges (@wordpress/react-native-bridge, @wordpress/react-native-aztec) are also private: true and not published. The iOS dep chain pulls in Carthage + a custom Aztec fork; the Android side pulls in custom WordPress-Mobile gradle modules.
3. There is no "use Gutenberg Mobile out of the box" path today. Both the WordPress iOS app and the WordPress Android app consume Gutenberg Mobile via wordpress-mobile/gutenberg-mobile, which vendors Gutenberg as a git submodule and builds the bundle in-tree. That is the supported integration model, and it is the only one with a working precedent.
4. wp-native currently has zero editor code, zero editor docs, zero editor deps — confirmed by grep. There is no infrastructure to wrap.
5. The right move is therefore not "wrap @wordpress/react-native-editor" — that wrapping doesn't exist to do. The right move is to define the wp-native editor surface (component API + ability contracts) decoupled from any specific Gutenberg Mobile runtime version, and treat the runtime as a swappable native module the consumer app links in — initially via the gutenberg-mobile submodule pattern, later (if/when WP-Mobile fixes Gutenberg-on-React-19) via a real npm dep.

That design is what the rest of this comment proposes.

---

What I investigated (and what the code actually says)

1. wp-native repo — no prior editor work

$ grep -irE 'editor|gutenberg|registerGutenberg|isolated-block' \
    packages/ plugins/ docs/ README.md | grep -v dist/ | grep -v node_modules

Returns only passing mentions — wordpress.ts transport docstring ("only import from inside Gutenberg blocks"), ROADMAP.md v0.1 non-goal ("Native Gutenberg authoring"), README architectural notes. No code, no types, no package, no deps. This is greenfield in wp-native.

Existing package layout for context:

wp-native/
├── packages/
│   ├── api-client/   wp-native-client — universal Abilities client
│   ├── shell/        wp-native-shell — RN providers + AuthGate + ability screens
│   ├── meta/         meta package
│   └── theme/        design token primitives
└── plugins/
    └── wp-native-auth/  WP plugin — 8 auth abilities

useAuth() in wp-native-shell already exposes { user, isAuthenticated, sessionExpired, client, login(), logout(), refreshSession(), … } where client is the WPNativeClient (packages/shell/src/auth/context.tsx:267). The editor package consumes that exact surface — no new auth plumbing needed.

2. @wordpress/react-native-editor — what it actually is

Read directly from WordPress/gutenberg/trunk:

package.json:

{
  "name": "@wordpress/react-native-editor",
  "version": "1.121.0",
  "private": true,                     // ← NOT published to npm
  "main": "src/index.js",
  "dependencies": {
    "@wordpress/api-fetch":         "file:../api-fetch",
    "@wordpress/block-editor":      "file:../block-editor",
    "@wordpress/block-library":     "file:../block-library",
    "@wordpress/blocks":            "file:../blocks",
    "@wordpress/components":        "file:../components",
    "@wordpress/data":              "file:../data",
    "@wordpress/edit-post":         "file:../edit-post",
    "@wordpress/element":           "file:../element",
    "@wordpress/hooks":             "file:../hooks",
    "@wordpress/i18n":              "file:../i18n",
    "@wordpress/react-native-aztec":  "file:../react-native-aztec",
    "@wordpress/react-native-bridge": "file:../react-native-bridge",
    "react-native": "0.73.3",
    // …17 more native deps with pinned versions
  }
}

Every @wordpress/* dep is file:../* — only resolvable inside the Gutenberg monorepo. RN is pinned to 0.73.3. wp-native peer-deps react-native >=0.80.

src/index.js:

const registerGutenberg = ( { beforeInitCallback, pluginTranslations = [] } = {} ) => {
  class Gutenberg extends Component {
    constructor( props ) {
      // setupLocale(...), beforeInitCallback, lazy require('./setup')
      this.editorComponent = setup();           // = initializeEditor('gutenberg', 'post', 1)
      doAction( 'native.pre-render', parentProps );
      this.filteredProps = applyFilters( 'native.block_editor_props', parentProps );
    }
    render() { return cloneElement( this.editorComponent, this.filteredProps ); }
  }
  registerComponent( 'gutenberg', () => Gutenberg );  // ← AppRegistry root
};

The shape registerGutenberg() registers 'gutenberg' as a React Native AppRegistry component — i.e. it expects to be the root component of a standalone app, launched by native iOS/Android code (UIViewController / Activity) that mounts the RN view with rootTag and props (initialData, initialTitle, postType, capabilities, rawStyles, rawFeatures, locale). It is not a <GutenbergEditor/> React element you compose inside an expo-router screen.

Project status doc (docs/contributors/code/react-native/README.md):

The React Native mobile editor is currently unmaintained on trunk and is known to be broken following the upgrade to React 19 (#61521). React 19 is not compatible with the current Gutenberg Mobile setup … If a fix is required, branch from the most recent React Native release — tag rnmobile/1.121.0 at commit e63b8b8 — and cut a minor release from there.

Tracking issue WordPress/gutenberg#71336 — "Upgrading to React 19" — most tasks done on web; Gutenberg Mobile path forward is explicitly TBD ("The WP Mobile project is actively exploring paths forward for the block editor in the mobile apps, aiming to reduce complexity and improve alignment with the Gutenberg web project").

3. @wordpress/react-native-bridge and @wordpress/react-native-aztec

Both also "private": true (verified from package.json). Bridge README says verbatim:

This package is not yet published to npm. You can use it locally: $ npm install ./gutenberg/packages/react-native-bridge --save

iOS install requires Xcode project linkage + Gutenberg.podspec. Android install requires editing MainActivity.java + gradle includes. Aztec on iOS pulls in Carthage and a WordPress-Mobile fork of react-native-slider/video.

4. How WP-iOS and WP-Android actually consume Gutenberg Mobile

Via wordpress-mobile/gutenberg-mobile:

git clone --recurse-submodules https://github.com/wordpress-mobile/gutenberg-mobile.git
# Gutenberg is a git submodule under ./gutenberg
nvm install && npm install
npm run start:reset  # serves the Metro bundle
npm run core ios     # or core android

Gutenberg-mobile is a monorepo with Gutenberg as a submodule that produces an iOS framework + Android AAR bundle. WP-iOS and WP-Android link those native artifacts. There is no "npm install" path. Repo is active (last commit 2026-05-09).

5. RULES.md compliance — "what already exists"

• Existing in wp-native that the editor must integrate with: wp-native-client (execute(name, input)), wp-native-shell useAuth() (provides client), AuthFetchTransport (bearer-token lifecycle, 401 retry, refresh rotation), ThemeProvider / useTheme() (design tokens). Reuse all of these.
• Existing in WordPress core / Gutenberg that solves "editor as React component": nothing usable. The only React-Native editor surface in the WP ecosystem is @wordpress/react-native-editor, which has the constraints documented above. No "Gutenberg as a published library" exists for either web or native — same finding as MEMORY.md's Blocks Everywhere posture (the web composed surfaces <EditorInterface> / <VisualEditor> / <DocumentTools> are private and entity-coupled; on native, the closest equivalent is even more tightly coupled — registered as an AppRegistry root with a native bridge).
• Layer purity check: zero EC-specific names should appear in the proposed package. Ability names (extrachill/forum.reply.editor.load) live in consumer screen props, never in package source. Verified against the proposed API below.

---

Design proposal

Package name and path

packages/editor/    →    npm: wp-native-editor

Sibling to packages/shell / packages/api-client. New workspaces entry inherits from the root package.json already-globbed packages/*.

File tree

packages/editor/
├── package.json                  // name: wp-native-editor, private during pre-alpha
├── tsconfig.json                 // extends ../../tsconfig.base.json
├── README.md                     // consumer integration guide
├── EDITOR.md                     // contract doc (mirrors SHELL.md style)
├── homeboy.json                  // version-bump policy
├── src/
│   ├── index.ts                  // public exports
│   ├── component/
│   │   ├── editor-screen.tsx     // <WPNativeEditorScreen> — full-screen, nav-aware
│   │   ├── editor-host.tsx       // <WPNativeGutenbergEditor> — pure embed primitive
│   │   ├── types.ts              // EditorProps, EditorState, EditorContext shapes
│   │   └── chrome.tsx            // header, save button, dirty indicator (theme-driven)
│   ├── runtime/
│   │   ├── runtime.ts            // GutenbergRuntime interface (the swap-point)
│   │   ├── runtime-context.tsx   // RuntimeProvider, useRuntime()
│   │   ├── runtime-types.ts      // EditorInitProps, EditorBridgeEvents
│   │   └── stub-runtime.ts       // dev/test stub — text-only placeholder, no native deps
│   ├── abilities/
│   │   ├── contracts.ts          // load/save/autosave/media TypeScript contracts
│   │   ├── load.ts               // useEditorLoad(loadAbility, context) hook
│   │   ├── save.ts               // useEditorSave(saveAbility) hook
│   │   ├── autosave.ts           // useEditorAutosave(autosaveAbility, intervalMs) hook
│   │   └── media.ts              // buildMediaUploadHandler(mediaAbility, client)
│   ├── state/
│   │   ├── dirty.ts              // useDirtyState() — tracks content vs lastSaved
│   │   ├── lifecycle.ts          // load → idle → saving → saved → error machine
│   │   └── navigation-guard.ts   // useUnsavedChangesPrompt() — expo-router intercept
│   └── __smoke__/                // runtime-free unit smoke tests
└── dist/                         // tsc output

Layer purity invariant: runtime/runtime.ts defines an interface the editor talks to. No file under src/ imports @wordpress/* directly. The Gutenberg-Mobile bindings live in a separate adapter package — see below.

The runtime swap-point (the load-bearing decision)

Because @wordpress/react-native-editor is not consumable as an npm dep on React 19, wp-native-editor cannot statically depend on it. Instead:

┌───────────────────────────────────────────────────────────────┐
│  wp-native-editor (this package)                              │
│                                                               │
│  defines: GutenbergRuntime interface                          │
│           <WPNativeEditorScreen> / <WPNativeGutenbergEditor>  │
│           ability hooks (load, save, autosave, media)         │
│                                                               │
│  ZERO direct @wordpress/* deps. React 19 compatible.          │
└──────────────────────────┬────────────────────────────────────┘
                           │ implements
                           ▼
┌───────────────────────────────────────────────────────────────┐
│  Runtime adapter — provided by the consumer app               │
│                                                               │
│  Option A (today, only working path):                         │
│    wp-native-editor-gutenberg-mobile-adapter                  │
│    Consumes gutenberg-mobile via git submodule, exposes       │
│    GutenbergRuntime implementation. Pinned to rnmobile/1.121  │
│    branch with React-18-compat patch.                         │
│                                                               │
│  Option B (post-WP-Mobile-React-19-fix, hypothetical):        │
│    wp-native-editor-gutenberg-adapter                         │
│    Consumes @wordpress/react-native-editor from npm           │
│    (once published + React 19 compatible).                    │
│                                                               │
│  Option C (dev/Storybook):                                    │
│    stub-runtime (in-package) — renders raw block markup as    │
│    plain RN <Text>. Lets ability contracts be tested without  │
│    the native dep chain.                                      │
└───────────────────────────────────────────────────────────────┘

The framework ships A and B as separate adapter packages so the editor surface itself stays clean and version-stable. Today only stub-runtime (Option C) lives in-package; the real adapter lives in a sibling repo or sibling package until Gutenberg Mobile has a workable distribution story.

GutenbergRuntime interface (sketch)

// runtime/runtime.ts
export interface GutenbergRuntimeProps {
  initialContent: string;           // serialized block HTML
  initialTitle?: string;
  postType: string;                 // 'post' | 'forum_topic' | 'comment' | …
  locale: string;
  capabilities?: GutenbergCapabilities;
  mediaUploadHandler: MediaUploadHandler;
  onContentChange: (html: string, title?: string) => void;
  onSaveRequested: () => void;      // host requested save; runtime emits current html
  onError: (error: GutenbergRuntimeError) => void;
}

export interface GutenbergRuntime {
  /** React Native component that mounts the actual editor. */
  EditorView: React.ComponentType<GutenbergRuntimeProps>;

  /** Optional async setup hook — locale, block library, plugin translations. */
  initialize?: () => Promise<void>;

  /** Identifier surfaced in errors/telemetry. */
  readonly id: string;            // e.g. 'gutenberg-mobile@1.121.0', 'stub@dev'
  readonly version: string;
}

The runtime is injected via RuntimeProvider at the consumer-app root, sibling to WPNativeApp:

import { WPNativeApp } from 'wp-native-shell';
import { RuntimeProvider } from 'wp-native-editor';
import { gutenbergMobileRuntime } from 'wp-native-editor-gutenberg-mobile-adapter';

export default function RootLayout() {
  return (
    <WPNativeApp config={config} loginScreen={LoginScreen}>
      <RuntimeProvider runtime={gutenbergMobileRuntime}>
        <Slot />
      </RuntimeProvider>
    </WPNativeApp>
  );
}

This is the same pattern wp-native-shell uses for TokenStorageAdapter — platform-specific code is injected, never imported by the framework.

Public API — pick both, layered

The issue offers <WPNativeGutenbergEditor> or <WPNativeEditorScreen>. The right answer is both, layered:

1. <WPNativeGutenbergEditor> — the primitive. Pure embed. Caller owns the screen, the navigation, the header, the save button. Returns render output + an editor handle.
2. <WPNativeEditorScreen> — the convenience composer built on the primitive. Theme-styled header with title, dirty indicator, save button, back-with-unsaved-changes guard. The 80% case.

This mirrors wp-native-shell already shipping both AbilityList / AbilityDetail (primitives) and SectionScreen / SectionDetailScreen (composed convenience). Same precedent, same shape.

// Primitive (full control)
<WPNativeGutenbergEditor
  loadAbility="extrachill/forum.reply.editor.load"
  saveAbility="extrachill/forum.reply.editor.save"
  autosaveAbility="extrachill/forum.reply.editor.autosave"  // optional
  mediaAbility="extrachill/media.upload"
  context={{ replyId: 42 }}
  onSaved={(result) => router.back()}
  onError={(err) => showToast(err.message)}
/>

// Composed screen (convenience)
<WPNativeEditorScreen
  title="Reply"
  loadAbility="extrachill/forum.reply.editor.load"
  saveAbility="extrachill/forum.reply.editor.save"
  autosaveAbility="extrachill/forum.reply.editor.autosave"
  mediaAbility="extrachill/media.upload"
  context={{ replyId: 42 }}
  onSavedNavigateBack
/>

Critical layer-purity property: ability names are strings on consumer props. No EC names appear in wp-native-editor source. Verified.

Ability contracts — coordinated with Extra-Chill/extrachill-api#58

#58 already proposes the wire shapes. I align with them and add the client-side typings the editor package will ship. Tweaks proposed below; coordinate with #58 before locking either side.

// abilities/contracts.ts — wp-native-editor public types

/** Input passed to the load ability. */
export interface EditorLoadInput {
  context: Record<string, unknown>;   // e.g. { replyId: 42 } — opaque to framework
}

/** Result returned by the load ability. */
export interface EditorLoadResult {
  id?: number;                        // entity ID if loading an existing entity
  type: string;                       // 'forum_topic' | 'forum_reply' | 'comment' | …
  title?: string;
  content: string;                    // serialized block content (HTML w/ comments)
  raw?: string;                       // optional unprocessed source
  status?: string;                    // 'draft' | 'publish' | …
  context: Record<string, unknown>;   // echoed back; e.g. parent IDs
  permissions: {
    canSave: boolean;
    canUploadMedia: boolean;
    canAutosave?: boolean;            // ← addition vs #58
  };
  autosave?: {                        // ← addition: latest-autosave snapshot
    content: string;
    title?: string;
    savedAt: string;                  // ISO-8601
  } | null;
}

/** Input passed to the save ability. */
export interface EditorSaveInput {
  id?: number;
  parentId?: number;
  title?: string;
  content: string;
  context?: Record<string, unknown>;
}

/** Result returned by the save ability. */
export interface EditorSaveResult {
  id: number;
  status: string;
  content: string;                    // canonical server-rendered content
  permalink?: string;
  updatedAt: string;                  // ISO-8601
}

/** Input passed to the autosave ability. Same as save but server treats as draft snapshot. */
export interface EditorAutosaveInput extends EditorSaveInput {}
export interface EditorAutosaveResult {
  savedAt: string;
}

/** Media upload contract. */
export interface MediaUploadInput {
  // RN file-shape passed by Gutenberg Mobile's media picker
  uri: string;
  filename: string;
  mimeType: string;
  size?: number;
  context?: Record<string, unknown>;
}

export interface MediaUploadResult {
  // WordPress media-shaped — what Gutenberg Mobile expects from its mediaUpload handler
  id: number;
  url: string;
  mime: string;
  width?: number;
  height?: number;
  alt?: string;
  caption?: string;
}

Proposed deltas vs #58 (cross-link on both issues before locking):

1. Add autosave snapshot to EditorLoadResult so the editor can offer "restore unsaved draft" UX on reopen. Server-side autosave already exists via wp_create_post_autosave(); just surface it on load.
2. Add permissions.canAutosave — bbPress / comments may forbid autosave even when canSave is true. Cheap to add, expensive to retrofit.
3. Recommend strict typing of context at the consumer level (TypeScript generics on <WPNativeEditorScreen<Ctx>>) rather than baking entity-specific fields into the framework type. Keeps wp-native-editor generic.
4. Confirm content is serialized block HTML (with <!-- wp:* --> comments), not raw markdown — Gutenberg Mobile's parser requires the comment delimiters.

Integration with useAuth() and wp-native-client

Trivial — already-built primitives. Every ability call inside the editor goes through client.execute() exactly like the existing AbilityDetail screen (packages/shell/src/screens/ability-detail.tsx:74):

// abilities/load.ts (sketch)
export function useEditorLoad(loadAbility: string, context: Record<string, unknown>) {
  const { client } = useAuth();   // ← reuses existing wp-native-shell context
  const [state, setState] = useState<LoadState>({ status: 'loading' });

  useEffect(() => {
    let cancelled = false;
    void (async () => {
      try {
        const result = await client.execute<EditorLoadResult>(loadAbility, { context });
        if (!cancelled) setState({ status: 'loaded', data: result });
      } catch (error) {
        if (!cancelled) setState({ status: 'error', error });
      }
    })();
    return () => { cancelled = true; };
  }, [client, loadAbility, JSON.stringify(context)]);

  return state;
}

No new transport. No new auth. Bearer token rotation already lives in AuthFetchTransport. 401-during-edit handling is inherited: sessionExpired flag flips in useAuth(), and <WPNativeEditorScreen> listens and shows a re-auth prompt while preserving the in-memory draft.

Native dependency requirements

For Option A (gutenberg-mobile adapter, only working path today):

Consumer app must:

1. Expo custom dev client (not Expo Go). Native modules required.
2. Add gutenberg-mobile as a git submodule OR vendor the prebuilt iOS framework + Android AAR.
3. iOS Podfile — pod-install Gutenberg from the submodule, add the Aztec Carthage step (carthage bootstrap --platform iOS --cache-builds --use-xcframeworks in react-native-aztec/ios).
4. Android settings.gradle + app/build.gradle — include ':@wordpress_react-native-bridge' + implementation project(...).
5. Pin React Native to a Gutenberg-Mobile-compatible version. rnmobile/1.121.0 ships RN 0.73.3 / React 18. This conflicts with wp-native-shell's peer dep react-native >=0.80 and react >=19. Resolution: the editor adapter's peerDependencies will declare a narrower range, and the consumer app pins to that. Until WP-Mobile ships a React-19-compatible cut, the editor adapter and the rest of wp-native cannot share a React version in the same app.
6. Metro bundler config — the .native.js extension rule + react-native-sass-transformer so SCSS in Gutenberg core blocks compiles.

This is documented as the adapter package's README.md problem, not the framework's problem. wp-native-editor itself adds nothing beyond a TS dev dep on react + react-native types.

For Option C (stub runtime, dev only):

Zero native deps. Useful for Storybook, for shell development without a custom dev client, and for unit tests of the ability contracts.

Lifecycle, dirty state, navigation guard

Each gets its own follow-up issue (see open questions). The proposed primitives:

// state/lifecycle.ts
type EditorLifecycle =
  | { status: 'loading' }
  | { status: 'idle';   loaded: EditorLoadResult }
  | { status: 'dirty';  loaded: EditorLoadResult; draft: EditorDraft }
  | { status: 'saving'; loaded: EditorLoadResult; draft: EditorDraft }
  | { status: 'saved';  saved: EditorSaveResult }
  | { status: 'error';  error: Error; lastDraft?: EditorDraft };

// state/navigation-guard.ts — uses expo-router's `useFocusEffect` + `BackHandler`
useUnsavedChangesPrompt({
  shouldBlock: lifecycle.status === 'dirty' || lifecycle.status === 'saving',
  promptMessage: 'You have unsaved changes. Leave anyway?',
});

shouldBlock derived from lifecycle, not stored separately. Single source of truth.

Non-goals (confirmed)

• ❌ WebView primary runtime — confirmed. Issue explicitly forbids it; investigation confirms it's the wrong architectural call for the editor surface itself (different conclusion may apply to the unsupported-block fallback, where Gutenberg Mobile already uses a WebView internally — out of scope here).
• ❌ @automattic/isolated-block-editor revival — confirmed. IBE is a web/DOM abstraction; React Native has no DOM. Not applicable.
• ❌ EC-specific names baked into the framework — confirmed. All ability names live in consumer screen props. Grep-verifiable invariant.
• ❌ Wrapping @wordpress/react-native-editor as an npm dep — confirmed infeasible today. Not on the table.
• ❌ Block authoring inside wp-native itself — out of scope. wp-native consumes Gutenberg Mobile's block library; defining new blocks is consumer territory.

---

Open questions (file as follow-up issues if this design lands)

1. Autosave semantics — server-side via wp_create_post_autosave() vs. ability-owned table? wp_*_autosaves is well-trodden for post-typed entities but does not work for bbPress replies or comments (different post-meta layout). Likely answer: per-entity autosave storage owned by the load/save ability implementation, returned via EditorLoadResult.autosave. Confirm with extrachill-api#58.
2. Offline editing — out of scope for v0.1? Current AuthFetchTransport has no offline queue. Decision: ship online-only first, file separate issue for offline draft persistence using expo-sqlite or expo-secure-store.
3. Dirty-state granularity — content-hash compare vs. Gutenberg Mobile's own isEditedPostDirty selector? Gutenberg Mobile's @wordpress/data store knows; we should consume core/editor selectors through the runtime's bridge rather than re-deriving. Spec'd as a follow-up.
4. Navigation guards on expo-router — does expo-router v6 support useFocusEffect-based blocking, or do we need react-navigation's usePreventRemove? wp-native peers expo-router >=6 — needs validation.
5. React 19 / React 18 split — the load-bearing constraint. Options: (a) wait for WP-Mobile to publish a React-19-compatible Gutenberg Mobile (timing unknown — tracking issue #71336 is open); (b) drop wp-native-shell's React 19 requirement back to 18 until the editor can land on the same major; (c) ship the editor adapter as a separate consumer app that links Gutenberg Mobile and exchanges messages with the wp-native-shell host via deep links. This needs a separate design decision before any adapter code lands. File as a stand-alone tracking issue.
6. Media picker UX — Gutenberg Mobile's bridge exposes requestMediaPicker(source, filter, multiple, callback) that opens the host app's native picker. The adapter must wire that to expo-image-picker (or equivalent) before forwarding the file to the media.upload ability. Adapter-package concern, not framework.
7. Should adapter packages live in wp-native repo or sibling repos? — Argument for sibling: keeps wp-native core lean and React-19-clean; lets the adapter pin its own RN/React versions. Argument for in-repo: easier dogfooding. Recommend sibling repo (wp-native-editor-gutenberg-mobile-adapter) so wp-native's CI doesn't have to install Aztec/Carthage.

---

Recommended next steps

1. Land this comment as the design of record on Add native Gutenberg editor package #46. No code yet.
2. Cross-link to extrachill-api#58 with the contract deltas (autosave snapshot, canAutosave permission, context as consumer-typed generic).
3. Open follow-up issues for the open questions above, especially the React 18/19 split (question 5) — that decision blocks adapter work, and we shouldn't write any package code until it's resolved.
4. Once Q5 is resolved: scaffold packages/editor with stub-runtime + ability contracts + the two public components, ship it as wp-native-editor@0.0.1 (private, runtime-less). That's a real, testable, ship-able unit without needing Gutenberg Mobile linked yet.
5. Adapter package work happens in a separate repo on its own timeline, gated on the Q5 outcome and on whatever WP-Mobile does with React 19.

cc <@532385681268408341> — design ready for review. Not pushing code, not opening a PR.

[chubes4]

Coordination correction — server-side ability home

Orchestrator update: the server-side editor abilities referenced in the design comment above are not going in extrachill-api. That plugin is REST-wrapper-only per site rules (abilities own validation/sanitization/writes; the REST plugin must be thin pass-through and nothing else).

The server-side ability work is being redirected to Extra-Chill/extrachill-multisite (network-activated, correct home for cross-network abilities). A sibling minion is filing the tracking issue there now — link forthcoming.

Replace these references in the design above:

• "coordinated with Extra-Chill/extrachill-api#58" → coordinated with the forthcoming extrachill-multisite editor-abilities issue
• "Confirm with extrachill-api#58" (autosave semantics open question) → confirm with the extrachill-multisite issue
• "Cross-link to extrachill-api#58" (recommended next steps) → cross-link to the extrachill-multisite issue

Everything else in the design stands. The three proposed contract deltas — autosave snapshot on EditorLoadResult, permissions.canAutosave, context as a consumer-typed generic — still apply, just discussed against the multisite issue instead.

I'll edit this comment with the direct issue link once the sibling minion files it. The wp-native-editor side of the contract (TypeScript shapes shipped in packages/editor/src/abilities/contracts.ts) is unaffected by where the server-side counterpart lives.

[chubes4]

This issue is blocked by the React 18/19 decision tracked in #48. The runtime-agnostic packages/editor scaffold (stub runtime, ability contracts, public components) can proceed independently — only the adapter package work blocks on this.

[chubes4]

Parked. Per decision on #48 — native Gutenberg editor work is paused until WordPress Mobile ships a React 19-compatible @wordpress/react-native-editor. The runtime-agnostic scaffold (TypeScript ability contracts, public component API, stub runtime) does not justify shipping in isolation while there's no real adapter to consume it.

The design comment on this issue remains the design of record for when work resumes. Server-side editor abilities (extrachill-multisite#33) and the bearer-token multisite fix (#47) shipped independently and are reused regardless of when native authoring lands.

Closing this would lose the design notes; keeping it open as a parked tracking issue.