Add iOS Preload List #250

jkmassel · 2025-12-08T18:36:05Z

What?

Adds a preloading system that pre-fetches WordPress REST API responses and caches editor assets before the editor loads. By injecting cached data directly into the JavaScript runtime, the Gutenberg editor can initialize without waiting for network requests.

Why?

Editor loading performance isn't great when connecting to WP sites because Gutenberg needs a lot of API data. This fixes that issue (and simplifies how the editor loads – if we want to suggest the user install plugins, for instance, we should prepare the data ahead of time and inject it as part of EditorDependencies. If we want to pre-load a WKWebView to further speed up loading, it should go in EditorDependencies. A single loading path makes things very straightforward.

How?

New GutenbergKitLogic Module

Contains most of the framework logic – caching, networking, data models, etc
I developed it separately but left it extracted because it's Swift 6-compatible while the rest of the project isn't.
We can re-combine it if we want once the whole project is Swift 6-compatible but that wasn't the aim of this PR.

Preloading Infrastructure

EditorService - Top-level object that coordinates fetching dependencies.
EditorDependencies - Container for everything the editor needs to load.
EditorPreloadList - Bundles pre-fetched API responses (post types, themes, settings) for injection into JavaScript
EditorURLCache - Disk-based response caching with configurable TTL policies

See the docs for an outline of how it all works.

Demo App Enhancements

New SitePreparationView screen for testing preloading behavior
Controls to prepare dependencies, clear caches, and observe loading progress
Visual feedback showing whether dependencies are pre-loaded

Testing Instructions

I've added a lot of logic tests.

I recommend testing with the demo app on a real device. I used the following test sites:

vanilla.wpmt.co (to test a stock WordPress installation)
jetpack.wpmt.co (to test a Jetpack installation that uses plugins)
slow.wpmt.co (to test a very slow site that takes a long time to load anything)

Here's some interesting test cases:

Test by tapping "Prepare Editor". You'll see a progress bar in the site preparation screen, and once it's complete you won't see one in the editor.
Go back to the app root, then open a site, then load it without tapping anything else. You'll see a brief flash of progress bar – that's the editor loading everything from the HTTP cache, but without an injected EditorDependencies object. It's almost instant, but not quite fast enough to avoid detection. We could look at further improving this, but injecting EditorDependencies fully resolves it so IMHO that should be the path forward.
Clear the Preload Cache and load the editor – you'll see a progress bar indicating the loading process.
Hit "Prepare Editor" (which will create EditorDependencies from the HTTP cache), then tap "Prepare Editor ignoring cache". While that's in-progress, hit "Start Editor". The editor will load properly even though the download didn't finish because asset bundles are atomic – the next time you launch the editor, the one that was downloading will be used instead.

Review Suggestions

I'd suggest going commit-by-commit. The tests aren't terribly interesting, I'd suggest reading the names – they do what they say they do. The GutenbergKitLogic should be extremely boring – lots of small pieces that compose together. The EditorService, RESTAPIRepository, and EditorHTTPClient are probably the most interesting. I'd suggest mostly focusing on the adoption in GutenbergKit – how the logic is used to deliver the behaviour we want. I moved EditorViewController to a very simple state machine because we have multiple paths through that code.

jkmassel · 2025-12-08T18:38:30Z

src/utils/api-fetch.js

- * @todo Provide this data from the host app
- */
-const preloadData = {
+const defaultPreloadData = {


@dcalhoun I retained this here for the bundled editor and other offline use – I don't love having more than one source of truth, but it seemed like a pragmatic way to do it (especially in the absence of an Android implementation). We could move this to JSON and load it from Android and iOS in a single code path later, if needed?

Retaining this for now makes sense.

I like the idea of relocating it to a JSON file when we add an Android implementation. It seems ideal to have the native code always provide this value—either the fetched site data or the fallback value.

jkmassel · 2025-12-08T18:40:48Z

ios/Sources/GutenbergKit/Sources/Model/GBKitGlobal.swift

+/// This struct is serialized to JSON and injected into the WebView as `window.GBKit`,
+/// providing the JavaScript code with all the information it needs to initialize
+/// the editor and communicate with the WordPress REST API.
+public struct GBKitGlobal: Sendable, Codable {


I moved this into native code because I really wanted it under test – doing everything with strings left me with a bunch of hard-to-debug failures where I was passing something invalid to the JS side and trying to figure out the problem using the web debugger wasn't serving me well – it's a pretty straightforward object so I don't think it's a bad trade, but interested in y'alls thoughts.

Makes sense.

The number of times we pass/reassign these same values feels a little ceremonial, but some of it may be unavoidable and I'm sure there are situations where having GBKitGlobal will make unexpected outcomes less cryptic.

jkmassel · 2025-12-08T18:42:01Z

ios/Sources/GutenbergKit/Sources/Model/JSON.swift

+
+// Originally found at https://forums.swift.org/t/support-embedding-json-like-objects-in-swift-code/38329/13
+
+public enum JSON: Sendable, Equatable, Hashable, CustomStringConvertible {


We're getting a bunch of the data from the server as JSON, which we pass into the editor. The trouble is, if the server is misconfigured and sends non-JSON, it'll crash the editor. I'd rather get a validation error instead, so this object exists to give something slightly nicer and more strongly-typed than JSONSerialization to work with.

kean · 2025-12-09T13:32:32Z

ios/Sources/GutenbergKit/Sources/Model/EditorConfiguration.swift

+  /// Enables logging of all network requests/responses to the native host
+  public let enableNetworkLogging: Bool
+  /// Don't make HTTP requests
+  public let isOfflineModeEnabled: Bool


The name is a bit misleading and the documentation acknowledges that. It's not for offline mode but for scenarios when you open an editor without a site. In that scenario, which we might have for GBK-based comments, the user is still required to provide siteURL and all the other required parameters.

I would suggest to:

Remove isOfflineModeEnabled for now since there is currently no need for it

Refactor EditorConfiguration later and extract WP-site related field into a dedicated struct. The property with this type will be optional. If it's nil, that would be the indication to "load the editor without attempting to connect to a WP site".

Remove isOfflineModeEnabled for now since there is currently no need for it

If I do this, it'll break the bundled editor in the demo app

Refactor EditorConfiguration later and extract WP-site related field into a dedicated struct. The property with this type will be optional. If it's nil, that would be the indication to "load the editor without attempting to connect to a WP site".

I strongly agree with this as a future improvement.

kean · 2025-12-09T13:33:26Z

docs/preloading.md

+The preloading system consists of several interconnected components:
+
+```
+---------------------------------------------------------------------+


(nit) I would suggest to avoid committing documentation as it can be generated on the fly. The committed docs will likely get outdated quickly.

Can't say I agree here – I don't think someone should have to say "hey bot, please generate some docs for me" if they're trying to understand how the system works?

Any bots working on the codebase can/should also reference this to know how it's supposed to work.

I believe there is value in the documentation. I think the key is finding the right level of detail; the more detailed the static documentation, the more likely it will become outdated (or pose an unwieldy maintenance burden).

We might consider:

Reducing the number of examples; relying upon a single example showcasing the high-level concept of utilizing the disparate parts together.

Limit the times we document low-level implementation details—e.g., header filtering.

kean · 2025-12-09T13:38:31Z

ios/Sources/GutenbergKit/Sources/Stores/EditorURLCache.swift

+        )
+
+        self.cache.storeCachedResponse(response, for: URLRequest(url: url, method: httpMethod))
+        Thread.sleep(forTimeInterval: 0.05)  // Hack to make `URLCache` work


Can you elaborate what this is for? It shouldn't be required. Is it only for unit tests?

This is an unused DiskKeyValueCache class and EditorKeyValueCache protocol in this PR. Would it make sense to use these if URLCache doesn't provide the required guarantees? If no, the unused code needs to be removed. These classes are also currently public, which it looks like they should not be.

The tests fail without it, yeah. It seems like whatever thread safety is provided by the class comes at the cost of eventual consistency. If there were a callback when the data is actually committed that'd help a lot. I'd rather have a tiny delay in async functions but have guarantees that when the function returns I can immediately fetch what I just stored, so this isn't the worst trade-off.

I'd considered using the KeyValueCache objects as a replacement, but I figured if we'll adopt them we should probably do so wholesale across the library? I don't really want to do that as part of this PR so WDYT about just dropping them for now and we can revisit this question later?

I dropped EditorKeyValueCache in c8d4f11

kean · 2025-12-09T15:59:56Z

ios/Demo-iOS/Sources/GutenbergApp.swift

+            NavigationStack(path: $navigation.path) {
                AppRootView()
+                .navigationDestination(for: RunnableEditor.self) { editor in
+                    EditorView(configuration: editor.configuration, dependencies: editor.dependencies)


(nit) ideally, you'd want to show these as modals to match how it's used in the apps

Addressed in 50800e0.

kean · 2025-12-09T16:11:10Z

ios/Sources/GutenbergKit/Sources/EditorHTTPClient.swift

+/// A protocol for making authenticated HTTP requests to the WordPress REST API.
+public protocol EditorHTTPClientProtocol: Sendable {
+    func GET(url: URL) async throws -> (Data, HTTPURLResponse)
+    func OPTIONS(url: URL) async throws -> (Data, HTTPURLResponse)


(just checking) Is OPTIONS supposed to be used to fetch settings?

(nit) I'd suggest to provide a single perform(request: URLRequest) as part of the protocol (or `perform(_ method:url:) as an alternative). It's trivial to construct a request with an HTTP method you want. The naming (all caps) doesn't look like idiomatic Swift.

Is OPTIONS supposed to be used to fetch settings

Yep – it wants the settings schema, not the settings themselves

kean · 2025-12-09T16:12:11Z

ios/Sources/GutenbergKit/Sources/EditorHTTPClient.swift

+    private func perform(request: URLRequest) async throws -> (Data, HTTPURLResponse) {
+        var signedRequest = request
+        signedRequest.setValue(self.authHeader, forHTTPHeaderField: "Authorization")
+        signedRequest.timeoutInterval = 60


(nit) 60 is the default timeout interval.

Addressed in 71f68fa

kean · 2025-12-09T16:12:47Z

ios/Sources/GutenbergKit/Sources/EditorLogging.swift


-func log(_ level: EditorLogLevel, _ message: @autoclosure () -> String) {
+
+public func log(_ level: EditorLogLevel, _ message: @autoclosure () -> String) {


I presume the logger should be internal.

Yep! Addressed in 6aa25bc

kean · 2025-12-09T16:15:17Z

ios/Sources/GutenbergKit/Sources/EditorViewController.swift

+
+        // If we don't have dependencies yet, we need to load them
+        if case .start = viewState {
+            self.viewState = .loading(self.loadEditorTask)


(nit) it' a bit confusing that accessing a property triggers a request

WDYT about 5cdbc5b?

kean · 2025-12-09T16:17:05Z

ios/Sources/GutenbergKit/Sources/EditorViewController.swift


        if isWarmupMode {
-            startEditorSetup()
+            self.loadEditorWithoutDependencies()


I'm not sure a separate code path is needed. In the previous implementation, it would simply load the editor which will in turn prefetch any of the assets it needs.

Noted about this elsewhere, but the prefetching is inverted and this is just for pre-compiling JS now.

kean · 2025-12-09T16:31:27Z

ios/Sources/GutenbergKit/Sources/EditorViewController.swift

+    private var loadEditorTask: Task<Void, Never> {
+        Task(priority: .userInitiated) {
+            do {
+                let dependencies = try await self.editorService.prepare { @MainActor progress in


I'm not completely sure I understand the new refresh logic, but it seems that it didn't retain the behavior from the previous system.

Coalescing . Previously, the editor would start fetching the resources in warmup using a shared EditorService (per site). If it's the first launch and the user opens the editor during prefetching, the editor subscribes to the same task. If the user opens the editor quickly after the refresh finishes, it would not performs the requests again.

Refresh. In the previous implementation, warmup would refresh the dependencies in the background. I can't seem to find where it refreshes the data. It appears that once the data is cached, the editor users cached data indefinitely.

There may be a couple more things.

The host app should have control over how the editor loads. In a low-battery or cellular connection situation, for-instance it might be preferable to just re-use what's on-device already. Reducing the coupling between loading and displaying the editor allows a lot of app-side changes without modifying the library. It also allows atomic bundles – if a download is in progress we don't need to wait for it and can just display the editor immediately (or the host app can decide to wait for the download to finish). Lastly, splitting this out means that the editor can load entirely offline (whereas that doesn't currently work in trunk).

So, the refresh logic is not in the scope of the PR, it will not be part of GBK, and it will be implemented separately in the host apps, correct?

the coupling between loading and displaying the editor allows a lot of app-side changes without modifying the library

I would still consider keeping as much of this logic in GBK to make it easier to iterate on it and provide the app with only the minimum required public API. Currently, it just needs to let the editor know when it needs to refresh the data, which is handled by the warmup method. The app doesn't need to know anything else, so there is minimum coupling between the host app and the framework.

if a download is in progress we don't need to wait for it and can just display the editor immediately

I believe this was also the case in the previous implementation. It would write a new manifest on disk for the editor to use only when all assets are loaded. If manifest changes, it would only fetch the assets that have changed. The editor would use the previous manifest until the new one is fully ready. I think it's more clear with explicit bundles, but it also requires a bit more management of files and directories.

So, the refresh logic is not in the scope of the PR, it will not be part of GBK, and it will be implemented separately in the host apps, correct?

Yes and no – everything the apps need for refresh is in EditorService. You can check out how SitePreparationView.prepareEditor / SitePreparationView.prepareEditorFromScratch work. There are basically four scenarios an app can choose:

The app does nothing to prepare the editor, so the editor loads its own dependencies while displaying a progress bar. Those dependencies are cached and reused indefinitely. (I can see a good argument that in this case there should be a non-indefinite caching policy).

The app prepares the editor with default params, which reuses the local cache.

The app prepares the editor by making an EditorService with cachePolicy: .maxAge(seconds:), setting some value that makes sense for its needs.

The app prepares the editor by making an EditorService with cachePolicy: .ignore, which reloads everything.

The editor would use the previous manifest until the new one is fully ready.

I couldn't find any guarantee of this – it seems actuallyRefresh is gated behind Task.sleep(for: .seconds(7)), but I couldn't find anything that would prevent dependencies(for configuration from running at the same time (particularly on a slow internet connection if the user left one post and reloaded another while using a shared EditorService).

I think it's more clear with explicit bundles, but it also requires a bit more management of files and directories.

Yeah, there's more path management, though I liked that cleanup is very straightforward and fast. Trade-offs, I guess🤷

dcalhoun

The implementation tested well for me. I never encountered a situation where the editor failed to load, and it loaded quickly during my testing on my iPhone SE.

I noticed a couple of things while testing.

First, there appears to be a retain cycle causing the WebView to never be released. We addressed a similar issue before in WP-iOS.

Editor view memory leak

Second, I note there is an unexpected margin or overflow scroll occurring atop the editor. It only seems to occur for the default editor, though.

Unexpected margin atop editor

ios/Demo-iOS/Sources/Views/SitePreparationView.swift

ios/Demo-iOS/Sources/Views/EditorView.swift

ios/Demo-iOS/Sources/Views/SitePreparationView.swift

dcalhoun · 2025-12-09T20:55:16Z

ios/Sources/GutenbergKit/Sources/Model/GBKitGlobal.swift

+/// This struct is serialized to JSON and injected into the WebView as `window.GBKit`,
+/// providing the JavaScript code with all the information it needs to initialize
+/// the editor and communicate with the WordPress REST API.
+public struct GBKitGlobal: Sendable, Codable {


Makes sense.

The number of times we pass/reassign these same values feels a little ceremonial, but some of it may be unavoidable and I'm sure there are situations where having GBKitGlobal will make unexpected outcomes less cryptic.

ios/Sources/GutenbergKit/Sources/EditorLogging.swift

ios/Sources/GutenbergKit/Sources/EditorViewController.swift

dcalhoun · 2025-12-09T22:24:39Z

src/utils/api-fetch.js

- * @todo Provide this data from the host app
- */
-const preloadData = {
+const defaultPreloadData = {


Retaining this for now makes sense.

I like the idea of relocating it to a JSON file when we add an Android implementation. It seems ideal to have the native code always provide this value—either the fetched site data or the fallback value.

jkmassel · 2025-12-09T23:11:58Z

@dcalhoun, it won't let me reply inline, so just noting this one:

First, there appears to be a retain cycle causing the WebView to never be released. We wordpress-mobile/WordPress-iOS#24936 a similar issue before in WP-iOS.

I saw this as well – I saw the note in the code about /// Hiding the conformances, and breaking retain cycles. so I suspect something's no longer working as it should. I'm also not entirely certain why GutenbergEditorController exists in the first place, so I'd like to look into that as part of the "Cache the web view" work. I suspect that ensuring there's only ever a single GBWebView floating around (or at least, one per UIScene) will solve this for us.

Co-authored-by: David Calhoun <github@davidcalhoun.me>

dcalhoun · 2025-12-11T19:14:28Z

In terms of the architecture, I suggest another quick pass to see if any components could be collapsed into larger parts. There are some abstractions that were perhaps added prematurely. I'd suggest keeping things as simple as possible for now to make it easier to change it in the future.

I second this suggestion. The changes do feel far more complex than the previous implementation. Some of that complexity may be necessary—we are implementing far more capability—but there may also be opportunity to reduce complexity through fewer abstractions (if unnecessary or lower-value ones exist).

I can't say I was able to test or review everything, as there are many changes in this PR, some unrelated to the primary change.

This describes my experience as well. I did my best to comprehend and test the changes, but the quantity of changes makes it challenging to achieve a high level of confidence.

ios/Demo-iOS/Sources/Views/EditorView.swift

jkmassel · 2025-12-13T01:00:32Z

I'd suggest to move the settings screen under the context menu and/or as a separate button in the editor list.

This stuff is all site-specific – you can't set it globally.

jkmassel · 2025-12-13T01:04:36Z

Remove the API for tracking EditorProgress and UIEditorProgressView.

The editor uses this internally to render the progress bar, so I'm not sure this makes sense.

We most likely won't need it as the dependencies are prefetched before you open the editor for the first time.

Unless you plan to disable all paths to the editor until this preloading is complete, there's no way to guarantee this. Finding a way to message that the editor isn't ready yet is substantially more complicated than the editor showing a loading screen.

If the loading takes a lot of time, we can simply show fake messages like "Fetching Gutenberg", "One mississippi, two mississippi...", etc to entertain the user. IT doesn't need to show what's actually happening.

We're not trying to entertain the user, we're trying to help them understand what's going on. After 10s of loading, a "cute" message becomes infuriating – the user just wants to know what's going on.

Co-authored-by: David Calhoun <github@davidcalhoun.me>

Co-authored-by: Alex Grebenyuk <grebenyuk.alexander@gmail.com>

jkmassel · 2025-12-13T01:13:51Z

Simplify the code that loads dependencies in EditorViewController. It currently takes almost three screens at the top of the class that are mostly dedicated to excessive inline documentation. I would also consider using async/await to implement this sequence – it's less code and easier to follow. It's a pretty trivial operation – show spinner, perform one async task, handle errors, and the code should reflect that.

Done in 354d8f9, but I retained the code flow explanations because it's asynchronous between the VC and JS, and I'd like someone to be able to follow along without having to ask an LLM to explain it.

jkmassel · 2025-12-13T01:16:40Z

Remove EditorErrorView, EditorErrorViewController, and use ContentUnavailableView directly and UIHostingController directly.

Done in 935fd8a

jkmassel · 2025-12-13T01:27:33Z

Remove EditorHTTPHeaders - it should suffice using URLRequest directly. It was not clear what the component was for, so maybe I missed something.

HTTPURLResponse.allHeaderFields returns [String:Any] which is incorrectly case-sensitive. This will break REST API preloading (which requires certain HTTP Headers to be preserved) for sites that don't use the exact same casing we do in our project. We could try to remember to always do this any time we access a header, but it's a lot safer to just say "use EditorHTTPHeaders everywhere you need to work with HTTP Headers in the project" and always have the correct behaviour.

There's also no straightforward way to JSON-serialize [String:Any], which EditorHttpHeaders solves too.

jkmassel · 2025-12-13T02:55:38Z

Remove EditorCachePolicy and add a single opinionated policy that suits GBK.

There's no good one-size-fits-all solution here. For WP.com sites with Jetpack blocks, we should probably fetch on a regular basis because that code changes frequently. For self-hosted sites on lousy hosting, it probably makes sense to use .always and just have the app refresh the dependencies if it detects that the underlying Jetpack version has changed. This isn't something the library should need to know about, but we should be able to customize this functionality from the outside.

The (opinionated) default is .always, and I think that makes a ton of sense.

Instead of ignore, a button to clear the cache before loading an editor should be enough for testing.

.ignore allows you to spin up an EditorService that will always create a new bundle from the server. Deleting the old data isn't a substitute for this functionality – you want to say "make a bundle that has the absolute latest data, but don't delete what's already there".

Yes, it's useful for testing but that's not all it's there for.

Restore the Swift Observation framework pattern that was likely unintentionally removed in PR #250, allowing the code editor toggle to properly trigger `updateUIViewController` when the state changes.

jkmassel requested review from dcalhoun and kean December 8, 2025 18:36

jkmassel self-assigned this Dec 8, 2025

jkmassel added the [Type] Enhancement A suggestion for improvement. label Dec 8, 2025

jkmassel commented Dec 8, 2025

View reviewed changes

jkmassel mentioned this pull request Dec 8, 2025

Update to Swift 6 #252

Merged

jkmassel force-pushed the add/preload-list branch from 4e96ed4 to 930207d Compare December 9, 2025 06:21

jkmassel added 4 commits December 8, 2025 23:25

Add Preloader Logic

50f1b1d

Update GutenbergKit for the demo app

b8d37fd

Add site preparation screen

1aca406

Add documentation

7fb256b

jkmassel force-pushed the add/preload-list branch from 930207d to 7fb256b Compare December 9, 2025 06:25

jkmassel changed the title ~~Add/preload list~~ Add iOS Preload List Dec 9, 2025

jkmassel mentioned this pull request Dec 9, 2025

Add iOS Preload Tests #253

Merged

Remove old tests

efb4ed0

kean reviewed Dec 9, 2025

View reviewed changes

jkmassel added 2 commits December 9, 2025 11:12

Fix rebase issue

c95bc89

fix visibility issue

6aa25bc

jkmassel force-pushed the add/preload-list branch from 64a6df6 to 71f68fa Compare December 9, 2025 22:15

jkmassel added 2 commits December 9, 2025 15:31

Address HTTPClient feedback

b1b9a85

Remove EditorKeyValueCache

c8d4f11

jkmassel force-pushed the add/preload-list branch from 71f68fa to c8d4f11 Compare December 9, 2025 22:31

dcalhoun reviewed Dec 9, 2025

View reviewed changes

jkmassel and others added 3 commits December 9, 2025 16:16

Apply suggestions from code review

1d53407

Co-authored-by: David Calhoun <github@davidcalhoun.me>

Remove loadEditorTask synthesizing accessor

5cdbc5b

Update ios/Sources/GutenbergKit/Sources/EditorLogging.swift

f2dcb1c

Co-authored-by: David Calhoun <github@davidcalhoun.me>

kean reviewed Dec 12, 2025

View reviewed changes

ios/Demo-iOS/Sources/Views/EditorView.swift Outdated Show resolved Hide resolved

jkmassel added 2 commits December 12, 2025 14:32

Move editor start button

46b6838

Use modal editor

50800e0

jkmassel and others added 8 commits December 12, 2025 18:12

Remove editor loading state machine

354d8f9

Drop EditorErrorViewController

935fd8a

Use EditorLocalization

5682570

Fix a potential bug with editor loading

39cff26

Update ios/Demo-iOS/Sources/Views/SitePreparationView.swift

900dce7

Co-authored-by: David Calhoun <github@davidcalhoun.me>

Update ios/Demo-iOS/Sources/Views/EditorView.swift

304e4fb

Co-authored-by: David Calhoun <github@davidcalhoun.me>

Update ios/Demo-iOS/Sources/Views/EditorView.swift

e2a578a

Co-authored-by: Alex Grebenyuk <grebenyuk.alexander@gmail.com>

Rename to Foundation+Extensions.swift

9fba044

jkmassel force-pushed the add/preload-list branch from fa1346b to 9fba044 Compare December 13, 2025 01:13

Inline cachePolicy usage docs

7752bd5

jkmassel requested a review from kean December 15, 2025 16:12

kean approved these changes Dec 16, 2025

View reviewed changes

jkmassel merged commit 6486090 into trunk Dec 16, 2025
11 checks passed

jkmassel deleted the add/preload-list branch December 16, 2025 16:13

dcalhoun restored the add/preload-list branch December 17, 2025 19:14

dcalhoun deleted the add/preload-list branch December 17, 2025 19:36

jkmassel mentioned this pull request Dec 22, 2025

Add Android Preload List #260

Merged

dcalhoun mentioned this pull request Jan 6, 2026

fix: Toggle the code editor in the iOS Demo app #274

Merged


		// Originally found at https://forums.swift.org/t/support-embedding-json-like-objects-in-swift-code/38329/13

		public enum JSON: Sendable, Equatable, Hashable, CustomStringConvertible {


		func log(_ level: EditorLogLevel, _ message: @autoclosure () -> String) {

		public func log(_ level: EditorLogLevel, _ message: @autoclosure () -> String) {

Add iOS Preload List #250

Add iOS Preload List #250

Uh oh!

Conversation

jkmassel commented Dec 8, 2025

What?

Why?

How?

Testing Instructions

Review Suggestions

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dcalhoun Dec 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkmassel Dec 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kean Dec 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kean Dec 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkmassel Dec 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkmassel Dec 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkmassel Dec 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kean Dec 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

dcalhoun Dec 9, 2025 •

edited

Loading

jkmassel Dec 9, 2025 •

edited

Loading

kean Dec 9, 2025 •

edited

Loading

kean Dec 9, 2025 •

edited

Loading

jkmassel Dec 9, 2025 •

edited

Loading

jkmassel Dec 9, 2025 •

edited

Loading

jkmassel Dec 9, 2025 •

edited

Loading

kean Dec 9, 2025 •

edited

Loading

kean Dec 9, 2025 •

edited

Loading

dcalhoun Dec 9, 2025 •

edited

Loading