DEV Community: GoodBarber

Adding tools to an MCP server that ChatGPT has already approved

Pierre-Laurent Medori — Tue, 20 Oct 2026 12:03:14 +0000

On October 7 we added seven tools to our public MCP server: read the booking calendars of an app, list sessions, cancel a booking, manage closing days. The server is listed in ChatGPT's directory and in Claude's, and people also connect to it directly from Claude Code, Cursor and others. The question I asked before anyone wrote code: how do we add tools for the direct users without touching what ChatGPT approved?

One line of context: I run engineering at GoodBarber, an app platform, and our MCP server lets assistants manage the apps through an authenticated connection.

One server, three audiences

The first step was a map of who sees what. I had a rough idea; the code had the exact one.

audience	what it gets	what a new tool does
ChatGPT app	a frozen list of 45 tools, the ones OpenAI reviewed	absent from the list; a call to it is refused
Claude directory	the full catalog, which follows each deploy	appears with no new submission; the tool names shown on the listing page are updated by hand
Direct clients	the full catalog	appears

So a new tool is free for the Claude directory and for direct clients, and the frozen list keeps it away from ChatGPT. That could have been the whole plan.

The coupling no test covered

The ChatGPT side is a facade over the same catalog. It picks the 45 tools and overrides their descriptions, plus one schema. Everything else it serves, the titles, the input schemas, the annotations that say whether a tool reads or writes, comes from the code shared with every other audience.

That means a change made for the new tools, say a tweak to the helper that turns tool names into titles, or to the function that builds annotations, would also change what ChatGPT serves for tools OpenAI already reviewed. Nobody would notice: the existing test only checked the names and the order of the 45.

So step zero, before any booking code, was a test that freezes everything ChatGPT sees, for several configurations the facade serves: name, title, description, input schema, annotations, compared to a committed reference file. Any difference fails CI and names the tool. Simplified:

def test_chatgpt_surface_matches_reference():
    served = {tool["name"]: tool for tool in chatgpt_tools_for(SAMPLE_APP)}
    reference = json.loads(REFERENCE.read_text())
    assert served.keys() == reference.keys()
    for name, expected in reference.items():
        assert served[name] == expected, f"{name} changed for ChatGPT"

Then we checked that the test can fail. The first attempt changed a field, and the test stayed green. Not because the test was wrong: that field is rewritten by an override before it reaches ChatGPT, so the change never got there. The second attempt added a field nothing overrides, and the test failed, naming the tool. A guard you haven't seen fail is a guess.

A second test checks the other direction: none of the new tools reaches ChatGPT.

With both in place, the booking work could touch the shared code freely. If it moved something OpenAI had approved, CI would say so before a deploy did.

A tool that cancels bookings

Four of the seven tools read. The three that write are the reason this section exists.

Creating a closing day in the back office cancels every booking on that day and sends each attendee a cancellation email. If the app's calendars inherit closing days from a default one, the closure applies to all of them. A person in the back office sees a confirmation dialog. A model sees a tool description, and a tool description is a suggestion.

So the tool checks before it acts:

it counts the bookings that the closure would cancel, across every calendar it would apply to;
if there are any, it creates nothing and returns confirmation_required with the count;
it only goes ahead when the call carries cancel_existing_bookings: true;
it refuses past days;
it is annotated as destructive, and its description says what happens to attendees.

The model can still cancel twenty bookings, and nothing stops it from setting the flag on its first call. What it can't do is cancel them by default: a call that doesn't ask for it returns the count, and the description tells the model to show that count to the user and get a yes first. That part is an instruction, not a lock.

Deleting a closing day makes the day bookable again if the calendar opens on it, but restores none of the bookings the closure cancelled. That one is not destructive in itself, and it's the kind of thing a model would assume: undoing the closure undoes the cancellations. It doesn't, and the description says so.

Cancelling a booking uses the same call as the back-office button, with the same email to the attendee. A booking that is already cancelled comes back as "not found, nothing was changed" instead of an error, so a model that retries after a timeout, or after the attendee cancelled from their own link, doesn't report a failure that didn't happen.

Access: a permission, not a list of pilot apps

Booking data includes attendees' names and emails, so the tools got their own permission in our API credentials service, read-only or read-write, offered only to the app type that has bookings. Existing keys don't get it; someone has to tick it.

That gave us a safe deploy order with no list of pilot apps: ship the server first, with tools nobody can see because no key carries the permission; then create the permission, which is the moment they become available. One decision went the other way on purpose: new keys pre-select every service in read-only, and bookings follow the same rule as the others.

The metadata that drifts

The tools were live in minutes. The descriptions of the server took longer.

The server card builds its tool list from the catalog, so it showed the new tools right after the deploy: 157, up from 150. Its version, though, was written by hand, and it was already behind the version in our registry entry. Both moved to 1.3.0.
The registry entry has a 100-character description. Adding "bookings" meant "mobile app" became "app". The publishing token had expired, so that took a new login.
The Claude directory listing shows a list of tool names that is edited by hand and validated by a reviewer, one of the details I went through in what each MCP directory actually checks. The tools themselves were already available to Claude users; the listing just didn't say so yet.
The ChatGPT app needed nothing. Nothing it serves changed, and the frozen test is what lets us say that. The day bookings should reach ChatGPT, that will be a new version of the facade and a new submission, on purpose.

Before the deploy, every call to the booking API ran against mocks, since only the production server is allowed to call it. The first real call came after the deploy, from a test key with only the booking permission. It worked.

What I'd keep

Map your audiences from the code, not from memory. ChatGPT's frozen list was the part I knew about; the shared code underneath it was the part I didn't.
Freeze what a reviewer approved, not what you meant to ship. Names and order are what you think of. Schemas, titles and annotations are what a shared helper changes behind your back.
Watch the guard fail once. Our first attempt at breaking it changed a field that never reaches ChatGPT.
For a model, a confirmation dialog is a refusal with a number in it. Return what would happen, and require an explicit flag to make it happen.
Gate new tools with a permission. It gives you a deploy where the code is live and the capability isn't.

If your MCP server is listed somewhere: what exactly did the reviewer approve, and which test would tell you it changed?

How do you manage CORS for thousands of customer domains? Per tenant, with three answers instead of two

Pierre-Laurent Medori — Thu, 15 Oct 2026 13:19:58 +0000

Our domain registry can stop answering. It can also answer that a customer's domain is no longer allowed. Both cases leave the proxy without a usable current list, but only the first gives us a reason to reuse an older one.

That distinction shaped our per-tenant CORS cache. We keep valid results for 15 minutes and a fallback copy for 24 hours. An authoritative refusal erases that fallback, so the next outage cannot bring a removed domain back.

One domain per customer

At GoodBarber, the web version of each customer app has its own domain, either a platform subdomain or a custom one. We are piloting a proxy that lets widgets call third-party APIs while their private keys stay on the server. Its CORS policy has to fit that domain model, even while the service itself is limited to a small pilot.

Our first static allowlist was manageable for five pilot apps. It could not follow the platform's thousands of domains as customers changed them. Allowing arbitrary origins would also defeat the restriction we wanted; PortSwigger documents that mistake in its guide to CORS misconfigurations. We needed to resolve the list for each tenant.

The preflight does not know who is calling

An actual API call carries a short-lived token naming the tenant. Its preflight arrives earlier, without that token: CORS preflight requests do not carry credentials. We receive an origin, a proposed method and a list of header names, so the token cannot supply the tenant for this lookup.

The request path can. It contains an opaque connector handle belonging to one tenant. We resolve the handle, then the tenant's domains. Because this happens before token validation, the lookup must also tolerate requests from arbitrary callers.

Origins, exactly as a browser sends them

The registry returns a domain. A browser sends an origin, and the comparison is string equality, so the list has to be built the way a browser would write it.

The default port for the scheme is omitted: :443 for HTTPS, :80 for HTTP. Non-default ports are kept.
A custom domain yields two origins, with and without www, since customers publish both. A subdomain of ours yields exactly one.
An internationalised domain is converted to punycode, which is what the browser sends.
The response carries the one matching origin and Vary: Origin, as MDN recommends for an explicit origin. Never *, and Origin: null never matches.

A miss needs a reason

Once the main cache entry expires, the registry lookup can produce three different outcomes:

The registry…	What the proxy serves	What it stores
answers with domains	those origins	the list for 15 minutes, and a second copy for 24 hours
cannot be reached, answers an error or sends garbage	the 24-hour copy, if there is one	the main entry again, for 60 seconds
answers clearly that the tenant has no usable domain	no CORS headers	an empty list for 60 seconds, and it deletes the 24-hour copy

The outage path borrows the idea of stale-if-error. Apps can keep using a previously accepted origin while the registry is unavailable. Caching that fallback decision for 60 seconds reduces repeated lookups; it does not by itself guarantee a global request-rate bound when concurrent misses occur.

An explicit removal has a different meaning. If we kept its old list, a later registry outage could restore the revoked origin from the 24-hour copy. Deleting that copy makes the refusal survive the outage too.

The pre-auth path is bounded

Before any I/O, we check the handle's shape and hash it for use in cache keys. Unknown handles are cached as unknown for 60 seconds. If the shared cache is unavailable, an in-process cache lasting 5 seconds, with at most 4,096 entries, limits repeated database work.

The preflight path responds with 204. If neither the lookup nor its permitted fallback yields an allowed origin, the response omits CORS headers. Dependency errors therefore do not become a 500, and the browser cannot proceed with the cross-origin call after an unsuccessful preflight.

Treat your cache as input

The cache is shared infrastructure, so what comes out of it is validated like anything else that crosses a boundary. Values are JSON, never pickled objects. Every list read back is checked, item by item, against the same pattern that judged it on the way in. A value that exists but fails that check is ignored and logged as a tampering signal.

Review found a mismatch here. Normalisation accepted a hostname containing an underscore, but cache validation used a stricter rule and rejected it. That value would have been repeatedly written, discarded and fetched again, leaving both caches ineffective for the tenant. Applying the same rule on write and read removed the disagreement.

CORS is not the lock

These responses govern browser access. A client such as curl does not enforce them, so actual requests still undergo token validation and the connector's permission checks. Using an older CORS list leaves those checks in place; it changes which browser origins may read the responses.

The feature and its hardening landed on July 23, six minutes apart: the second commit is the adversarial review of the first. The module has 48 tests: normalisation, the three outcomes, the bounds of the pre-auth path, and the few static origins we add on top.

To test the distinction, cache an allowed domain, have the registry explicitly remove it, then make the registry unavailable. The domain should remain absent. Testing an outage alone would miss the case where a cache reverses a decision it had already received.

Fail-closed or fail-open? Decide per side effect, then check what your cache already decided

Pierre-Laurent Medori — Tue, 13 Oct 2026 12:08:46 +0000

Fail-closed: when something a decision depends on is unavailable, the answer is no.

Fail-open: the answer is yes.

Fail-bounded: the answer is yes, inside a limit that does not need the missing dependency.

"Fail-closed or fail-open" is the wrong question at the scale of a service. Ask it per dependency and per kind of request. And before you answer, check your cache client: ours was configured to swallow errors, which turns every security decision built on it into fail-open without anyone deciding so.

Why two words are not enough

The third definition has no standard name, and it is the one we use most. OWASP's principle is called fail securely, and it is usually read as "always closed". For a service that sits between customer apps and third-party APIs, always closed means that a cache outage takes every app's weather widget down with it. Always open means that the same outage removes the only brake on a connector that can charge a card.

Both camps are right about their half of the traffic. So the unit of decision cannot be the service.

The table

The proxy behind this table is one we are trialling at GoodBarber. It keeps third-party API keys on the server for widgets that run inside customer apps, and today it serves a few test tenants. Its security specification settles the question in one decision, written before the code: the degraded mode depends on the side effect. A connector is registered either as read-only or as side-effecting, next to its host and its allowed methods, and every dependency gets a row. Everything below is conditional on that flag being right. The proxy applies the column it is given. It does not infer the class from the traffic, so a connector wrongly registered as read-only gets the lenient column.

When this is unavailable	Read-only connector	Side-effecting connector
The keys that verify token signatures	refused, `503`	refused, `503`
The rate limiter's shared store	allowed, inside a per-process ceiling	refused, `503`
The kill switch	cannot be unavailable on its own: it lives in the primary database and is read on every request	same

The first row has no nuance. A signature you cannot check is not a valid signature, whatever the request does. The status code matters as much as the refusal: 503, never 401. A 401 tells the client its token is bad, and a well-behaved client responds by asking for a new one, which turns an outage of the key endpoint into a stampede on the token endpoint.

The third row is a placement decision. A kill switch that lives in a cache disappears exactly when the infrastructure is having a bad day, which is when you reach for it. Ours is a column in the database the request already needs.

The option in the middle

The second row did not start that way. In the first version, read-only traffic simply passed when the limiter's store was down. An adversarial review, run before the first commit of that code landed, flagged it, and the reason fits in one sentence. "Read-only" describes the effect on the third party, not the cost to us or to the customer's API quota. Fail-open on reads is still an unmetered pipe.

The fix is a few lines, and it is the whole idea of fail-bounded:

try:
    ok = hit(tenant) and hit(tenant, connector) and hit(tenant, host)   # shared store
except StoreUnavailable:
    if side_effecting:
        return FAIL_CLOSED                       # 503: no brake, no payment
    return ALLOW if local_window_allows(tenant, connector) else THROTTLED
return ALLOW if ok else THROTTLED

local_window_allows is a sliding one-second window kept in the worker's memory. It is cruder than the shared limiter and it needs nothing that can be down. It is also per process, so the real ceiling is that number multiplied by the number of workers. Reads keep flowing, and "how much" still has an answer.

The setting that had already decided

This is what I would check first in any codebase. Our Redis cache is configured with django-redis's IGNORE_EXCEPTIONS, which its documentation describes as memcached-like behaviour: when the server is unreachable, a read returns None and a write does nothing. For a cache, that is the right call. A cache that is down should look like a cache that is empty.

A rate limiter built on that client inherits the setting. incr does not raise. It returns None. A naive comparison then either crashes or, written a little differently, treats "no answer" as "under the limit". Nobody chose fail-open. A convenience flag, set once for caching, chose it for every security decision stacked on the same client.

A shared client's error policy is a security decision for everything built on top of it. So the limiter treats silence as a failure, explicitly:

current = cache.incr(key)
if current is None:              # the client swallowed a backend error
    raise StoreUnavailable       # silence is a failure, not "under the limit"

One of the six tests of that module exists only for this case, and its name says so: none_from_ignore_exceptions_is_treated_as_unavailable.

Here is the whole chain during an outage. Redis stops answering. incr raises nothing and returns None. The limiter calls that unavailable, and the table decides: 503 for a connector that can charge a card, a local ceiling for one that reads the weather.

How do you prevent SSRF in a proxy that calls third-party APIs? Never accept a URL

Pierre-Laurent Medori — Thu, 08 Oct 2026 12:03:13 +0000

The contract for our API proxy has no target-URL parameter. A widget sends a connector handle and a relative path. The server loads the destination registered for that connector, then checks whether it is still safe to call.

That choice rules out the usual request saying, in effect, "fetch this internal address for me". It leaves several ways for a registered destination to become unsafe, including DNS changes and redirects. Those are the cases the rest of this article covers.

Who gets to choose the destination?

We built this proxy for GoodBarber, where generated widgets need to call third-party APIs without receiving the private keys themselves. The AI extension feature is still a prototype in a small pilot. The proxy holds the credentials and injects them into outbound requests, which makes its destination checks part of the secret's protection.

The OWASP cheat sheet on SSRF distinguishes services that can restrict calls to known destinations from those that must fetch arbitrary URLs. We chose the first model so that an authenticated owner could approve a destination before a widget used it.

The decision: a handle, not a URL

The handle is a random identifier. It selects a server-side record containing the scheme, host, base path and permitted methods. The caller supplies the relative path, query and body:

What the widget sends            What the server already holds
-----------------------------    ---------------------------------------
handle:  k3J…x9  (opaque)        base URL:  https://api.example.com/v2
path:    /forecast?city=Paris    allowed hosts, allowed methods
body:    { … }                   the secret, encrypted

When the owner approves an API and supplies its key, the base URL goes through the same validation function used for subsequent requests. Approval records the intended destination; it cannot guarantee what that hostname will resolve to later.

What is left to defend

Each outbound request still has to satisfy these checks:

Vector	What we do
The host is an IP in disguise: `2130706433`, `0x7f000001`, `127.1`, octal forms	rejected before any resolution: a destination must be a real hostname, and a name whose labels are all numeric or hexadecimal is refused
The name resolves to an internal address	blocked on the resolved IP, not on the string: loopback, private ranges, link-local and its cloud metadata address, carrier-grade NAT, and their IPv6 equivalents
One public A record and one private one	every address in the answer is validated, and a single forbidden address rejects the whole answer
DNS rebinding between the check and the connection	one resolution, then the connection goes to the validated IP
An IPv4 address wrapped in IPv6	IPv4-mapped and NAT64 addresses are unwrapped and the embedded IPv4 is validated too
A redirect to somewhere else	redirects are never followed, the 30x status goes back to the caller as it is
`../` to escape the registered base path	the path is normalised first, then compared with the base path
Headers that change the meaning of the request	three headers are relayed from the client: `Content-Type`, `Accept`, `Accept-Language`. `Host`, forwarding headers and method overrides are set or dropped by the server
A proxy configured in the host's environment	the HTTP client ignores environment proxies
Lookalike hosts such as `api.example.com.evil.com`	host matching is exact equality, never a suffix or a pattern

The NAT64 case came from an adversarial review before the first commit. In the well-known prefix defined by RFC 6052, 64:ff9b::7f00:1 embeds 127.0.0.1. An IPv6 classification alone can miss the address a translating network would reach. The embedded IPv4 address needs validation too.

Cloud metadata is one reason that distinction matters. AWS added IMDSv2 in 2019 as defense in depth against SSRF and related paths to instance metadata. Our proxy rejects those destinations rather than relying on the target to resist the request.

Connect to the address you validated

Checking a name and then handing the same name to the HTTP client is two resolutions, and the second one can answer differently. The fix is to resolve once and pin.

def resolve_and_pin(host: str, port: int) -> str:
    ips = resolve_ips(host, port)               # one resolution, A and AAAA
    for ip in map(ipaddress.ip_address, ips):
        if is_blocked_ip(ip):                   # one bad address rejects the whole answer
            raise SsrfBlocked(host)
    return ips[0]                               # the address we will connect to

The request then goes to that IP, while TLS still verifies the real hostname:

url = httpx.URL(scheme="https", host=pinned_ip, path=path)
headers["Host"] = hostname                                              # the real name, set by the server
request = client.build_request(method, url, headers=headers, content=body)
request.extensions = {**request.extensions, "sni_hostname": hostname}   # SNI and certificate check too

The Host header and the SNI carry the real name, so certificate verification is as strict as on a normal call, and it is never disabled. The socket layer has nothing left to resolve. The client is created with follow_redirects=False and trust_env=False.

The read timeout that never fires

An upstream can keep a worker occupied by sending one byte every twenty seconds. That never trips a 25-second httpx read timeout, because the timeout limits the wait for each chunk. We therefore put a wall-clock deadline around the exchange, including body streaming:

async def forward(...):
    # httpx's read timeout restarts at every chunk. This deadline does not.
    return await asyncio.wait_for(_execute(...), timeout=TOTAL_DEADLINE)   # 30 s, for a 25 s read timeout

The response size is capped the same way, by counting the bytes actually streamed, not by trusting a Content-Length header.

The key arrives last

Decryption happens after the destination checks. A request rejected for its method, path, host or resolved address therefore does not load the plaintext credential. Once admitted, the request receives the key for the approved upstream.

What the decision costs

Adding another API requires another approved connector. A widget cannot discover an arbitrary endpoint and ask our server to call it. That restriction suits a platform where an app owner approves which services receive their credentials.

The egress code landed on July 7 with 105 tests, including 18 for SSRF cases such as numeric hosts, mixed DNS answers, NAT64 and rebinding. Its specification contains 19 egress requirements. The tests cover the checks; the request contract limits what those checks have to accept.

In a review of another proxy, I would start where the outbound URL is constructed. Trace each component back to its source, then follow the chosen host through resolution and connection. A validator can be correct while the HTTP client quietly makes a different request.

How do you give local content in a WKWebView a real https origin? (iOS 17)

Pierre-Laurent Medori — Thu, 01 Oct 2026 11:45:29 +0000

On September 16 I opened a test widget on my iPhone. At the top, a quote that loads when the widget opens. Under it, two text areas and a Compare button that returns a similarity score. Two calls to the same third-party API with the same key: a GET for the quote, a POST for the score.

The quote appeared. The Compare button answered with the only sentence its code can say when that call fails: "Impossible de calculer la similarité. Veuillez vérifier votre connexion." Unable to compute the similarity, please check your connection. The connection was fine, my Android test phone did exactly the same, and in a browser both calls worked.

GET works, POST fails. I spent a morning on the verb. The cause was the page's origin, and the GET had never worked.

This piece is about that origin: where a page in a WKWebView gets one when its files live on the device, how our iOS engine now serves them from a fixed https://secure.internal with a proxy API that arrived in iOS 17, and what changing an origin breaks in places no crash log reaches. The widget comes back at the end, once the dates make sense.

Why local content needs an origin at all

At GoodBarber, an app builder for native iOS and Android apps, some sections of an app are web content: custom code written by the app's owner, HTML widgets, extensions. The files live on the device so that the section opens offline. On iOS they are displayed in a WKWebView.

How those files are served decides whether the page is a secure context, a prerequisite for APIs such as crypto.subtle. It also sets the origin seen by CORS and CSP checks, cookie behaviour, and where localStorage and IndexedDB data are stored.

One of those checks is ours. My team is piloting an extension builder, where I look after the backend: the owner of an app asks for a feature in a sentence, a model writes it, and the result runs in the app's web version and inside its native apps. A widget that needs a private API key never holds it. The page frames a small page served by our token issuer, gets a short-lived token, and calls a proxy of ours that keeps the key. The issuer lets only approved origins frame its page, through a CSP frame-ancestors directive. So the origin a native shell gives its local files decides whether any of those widgets can work at all. The builder has not shipped to customers, and the phones in this story are my own test devices.

Change the serving mechanism and all of that changes with it. We went through three versions in one year.

Three origins in one year

Period	How the page was served	Origin	What it cost
before June 2026	an HTML string with a custom base URL, files through a `WKURLSchemeHandler`	a custom scheme	not a secure context, an `Origin` header that third-party servers do not recognise, `Secure` cookies ignored, URL rewriting and a permissive CSP to hold it together
June to August 2026	a small HTTP server inside the app, bound to loopback	`http://127.0.0.1:<port>`	a secure context and plain HTTP semantics, but an IP address and a changing port in the origin
since September 2, 2026	a loopback CONNECT proxy in front of a TLS listener	`https://secure.internal`	iOS 17 minimum for this approach, and web storage starting from empty once

The second step was already a big one, and our iOS team built it as a real server: request parser, range requests for media, keep-alive, recovery when the listener dies. It also relays the page's cross-origin fetch calls, which the shell rewrites towards it. Loopback is a potentially trustworthy origin, so the page became a secure context and third-party scripts finally saw an http origin they understood.

The remaining problem was the port, assigned at runtime. There was no single origin to put in a remote allowlist. On July 30 the token issuer started accepting http://127.0.0.1:*, which is valid CSP and accepts any port, including any unrelated local server on the phone. A fixed https name would give the app and those services a value they could agree on.

WebKit will not hand over https

Apple's documentation for setURLSchemeHandler(_:forURLScheme:) rules out the direct approach: registering a handler for a scheme WebKit already handles, such as https, raises an exception.

Android takes the opposite position. shouldInterceptRequest lets an app answer any request, https included, and WebViewAssetLoader packages the pattern with a domain reserved for it, appassets.androidplatform.net. Our Android engine moved from file:// to that loader on July 31, a fixed https origin came with it, and the issuer accepted it the same day.

That Android approach does not transfer to WKURLSchemeHandler.

Why not a real certificate for a real domain?

The tempting shortcut is a public hostname that resolves to 127.0.0.1, a certificate from a public authority, and the private key shipped in the app. Let's Encrypt has a page about certificates for localhost whose answer is: don't. A private key distributed in an app is a compromised key, the certificate may be revoked, and the DNS lookup gives an attacker something to intercept. It also makes an offline section depend on DNS.

We could still use a certificate whose trust was limited to our own WebView. It did not need recognition from a public authority.

The piece that arrived with iOS 17

iOS 17 added proxyConfigurations to WKWebsiteDataStore, fed by the Network framework's ProxyConfiguration. Apple presented it at WWDC23 for network relays, with a remote relay in the example. Nothing says the proxy has to be remote.

import Network
import WebKit

// The CONNECT proxy is a listener our own app opened on loopback.
let proxy = NWEndpoint.hostPort(host: "127.0.0.1",
                                port: NWEndpoint.Port(rawValue: connectProxyPort)!)

var configuration = ProxyConfiguration(httpCONNECTProxy: proxy, tlsOptions: nil)
configuration.matchDomains = ["secure.internal"]  // only this name uses the proxy
configuration.allowFailover = false               // never try a direct connection

WKWebsiteDataStore.default().proxyConfigurations = [configuration]

Those two properties carry the design. With matchDomains, WebKit sends CONNECT secure.internal:443 to our listener instead of resolving the name, so the name never reaches DNS and the section opens in airplane mode. With allowFailover off, WebKit never falls back to a direct connection, so the name cannot leak to a resolver while our server is restarting.

Inside the app, three loopback listeners do the work:

A TLS listener serves the files. Its identity is embedded in the app: self-signed, RSA 2048, a single SAN secure.internal, TLS 1.2 minimum, ALPN http/1.1.
A CONNECT proxy on a port the OS assigns. It accepts exactly one request, CONNECT secure.internal:443, and pipes the bytes to the TLS listener. Anything else gets a 403.
A plain HTTP fallback for media, in case the media stack does not follow the data store's proxy.

The configuration is pushed again every time the server restarts, since the port changes, and before the WebViews are told to reload.

Accept one certificate, for one host

A self-signed certificate fails the system's trust evaluation. That is expected, and the navigation delegate is where it is settled. Ours is Objective-C. Here is the same logic in Swift:

func webView(_ webView: WKWebView,
             didReceive challenge: URLAuthenticationChallenge,
             completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {
    let space = challenge.protectionSpace
    guard space.authenticationMethod == NSURLAuthenticationMethodServerTrust,
          space.host.caseInsensitiveCompare("secure.internal") == .orderedSame,
          let trust = space.serverTrust else {
        completionHandler(.performDefaultHandling, nil)  // every other host: the normal path
        return
    }
    let chain = SecTrustCopyCertificateChain(trust) as? [SecCertificate]
    let leaf = chain?.first.map { SecCertificateCopyData($0) as Data }

    if leaf == pinnedCertificateDER {                     // byte-identical to the embedded one
        completionHandler(.useCredential, URLCredential(trust: trust))
    } else {
        completionHandler(.cancelAuthenticationChallenge, nil)
    }
}

The exception applies only to that host and that exact certificate. Every other host follows normal trust evaluation.

The embedded key is shared across our apps and can be extracted from a binary. We treat it accordingly. The design rests on the local routing and on the delegate's narrow trust decision; it does not give the certificate public authority or make it an app identity.

One more gate sits in front of the files. Loopback listeners are reachable by other processes on the device, so every URL starts with a random token generated for the session, and a request without it gets a 403.

Choosing the name

Since the name never touches DNS, it is cosmetic. It shows up in location.origin, in the web inspector and in server-side allowlists, never in front of a user. Two constraints still apply: the suffix must never be delegated on the public DNS, and no certificate authority must ever issue for it.

That rules out .app, which is a real top-level domain, and .local, which belongs to multicast DNS and answers on the local network. It points at .internal, which the ICANN Board reserved for private-use applications on July 29, 2024, permanently excluding it from delegation in the DNS root zone.

What we measured

The new engine landed on September 2, and the issuer swapped http://127.0.0.1:* for https://secure.internal the same day. These are the September 4 verification runs: iPhone 15 Pro simulator, iOS 17.4, our internal app in Debug, two real customer apps loaded in it.

Check	Result
Page loads logging `location.origin` and `isSecureContext`	43 loads across plugin sections, HTML widgets and scratch sections, 43 times `https://secure.internal` and `true`
`crypto.subtle`	present
TLS handshake through the tunnel	TLS 1.3, 6 ms
Import of the embedded identity	3.7 to 4.0 ms, measured four times
Live CONNECT tunnels	peak of 1, back to 0 after each cycle
Native bridge, storage round trip, cross-origin GET and POST relays	exercised on 9 scopes towards 3 remote hosts
Backgrounding for 50 seconds, then return	the WebView survives and the appear event fires again
Video rendering	not testable on the simulator, whose WebKit GPU process is denied GPU access; normal on a device

What the https origin changed

Mixed content appeared. Old custom code links http://fonts.googleapis.com/… stylesheets, in dozens of HTML files across 12 sections of a single test app. Under an http origin nobody noticed. Under https, WebKit blocks them as active mixed content and the page silently loses its fonts. The server now adds Content-Security-Policy: upgrade-insecure-requests to HTML documents, and to nothing else. Our Android engine met the same files after its own migration.

Tunnels have to die on the first EOF. A 28-minute capture showed 68 CONNECT tunnels alive at the same instant, all killed together with ENETDOWN when the app was suspended. Our relay waited for both directions to finish before closing, and WebKit keeps its side open and idle. A CONNECT tunnel is done as soon as either peer stops writing. With that rule, and a counter logged on every open and close, the peak is 1. ENETDOWN on suspension is now logged as a routine end of life, because it is one.

Web storage starts from empty. localStorage, IndexedDB and cookies are filed by origin, and WebKit offers no supported way to move them from one origin to another: WKWebsiteDataStore can enumerate and delete by origin, not read or rewrite. A custom section that kept a login token asks for the login once after the update. That is the visible price of an origin change.

The fourth change has no log line at all. It is the widget from the first paragraph.

Back to September 16

The phones ran internal builds of our shells from early summer. That morning I built both engines on my laptop and ran the same widget on fresh installs.

Surface	Native shell	GET, the quote	POST, the score
Web	none, a browser	ok	ok
iOS simulator	built that morning	ok	ok
Android emulator	built that morning	ok	ok, 48%, no console error
Test iPhone	internal build, early summer	a quote was displayed	error message
Test Android phone	internal build, early summer	a quote was displayed	error message

Same bundle, same backend, same key. The only variable left was the shell installed on the phones. Read the last two rows again: I wrote "a quote was displayed", not "ok". That morning I wrote "ok".

The verb was a good suspect, because a WebView does treat a request with a body differently. Browsers attach an Origin header to a same-origin POST and not to a same-origin GET, as the Fetch standard specifies, so any guard that compares Origin to an expected value is only ever exercised by POSTs. On Android, shouldInterceptRequest hands the app a WebResourceRequest with a URL, a method and headers, and no body. On iOS, our relay has to buffer the whole body before forwarding anything, and a GET has nothing to buffer. One fact should have cooled me down: both calls carried a bearer token in an Authorization header, which makes both of them preflighted cross-origin requests. For CORS, my GET and my POST were in the same class.

The coding agent I was pairing with asked for one trace from the phone, Safari's Web Inspector or chrome://inspect. I chose to build instead, because a build feels like progress. It worked, and this went into my notes: an outdated app relays the GETs and loses the body of the POSTs; check the build date before you look at the server. The second half is good advice. The first half is a mechanism nobody observed. The fix was right, the cause was invented.

Two days later I asked the same agent to draft an article from that session. Before writing the mechanism down for strangers, it checked it against git history, and the dates in this article do not allow it.

The iOS relay has buffered the complete body since the day it was written, June 4. There is no older relay that drops bodies for a phone to be outdated with.
On September 2 the issuer stopped accepting http://127.0.0.1:*. My commit message gives the reason: the feature is unreleased, and an app is rebuilt when the feature is activated for it. An iPhone build older than September 2 can no longer frame the token page. No frame, no token. No token, no call, whatever the verb.
Android builds older than July 31 load the page from file://. A file:// page has an opaque origin, and an opaque origin cannot be listed in frame-ancestors. No token there either.

So on those phones the GET could not have worked. Yet both showed a quote. The simulator still had the bundle it downloaded on the 16th, with the function that loads the quote, as the model wrote it (key name and author line shortened):

gbProxyFetch(KEY, "/v1/quotes")
  .then(function (res) {
    if (!res.ok) { throw new Error("Erreur API"); }
    return res.json();
  })
  .then(function (quotes) { /* render quotes[0] */ })
  .catch(function (err) {
    document.getElementById("quote-text").textContent =
      "« La simplicité est la sophistication suprême. »";
    /* ...and "Léonard de Vinci" in quote-author */
  })

On a shell that cannot frame the token page, the token request fails, the promise rejects, and this catch prints Leonardo da Vinci. That is what both phones were showing: Leonardo, in French. The POST went through the same failure with nothing to fall back on, so it told me to check my connection.

The asymmetry was not between two HTTP verbs. It was between two catch blocks. Nothing had worked on the phones; one of the two failures was dressed as a success. The evidence was on the screen: the API returns its quotes in English, the fallback is in French. And the SDK rejects with a typed error whose kind names the stage that failed, init when no token could be obtained. Both catch blocks received it. Neither read it.

An origin is versioned by the binary

A feature that lives in a web page inherits the page's origin, and inside a native app the shell chooses it: file://, a loopback port, a custom scheme, a fixed https name. CORS, CSP frame-ancestors, cookies and every server-side allowlist key on it. So every allowlist that names an origin is, in practice, a list of builds, and the builds are installed on people's phones on dates you do not control.

The switch of September 2 was a deliberate decision, and it holds: a rebuilt app carries the current shell, the current shell serves the origin the issuer expects, and the two move together. An app owner never meets the old origin. That works because the platform owns both ends, the native shell and the services behind it, which is also why every date in this article is known to the day. The one way to meet the old origin was to test an unreleased feature on an internal build from early summer, on the phone of the person who made the switch.

On the company blog I wrote about what quietly breaks when an app is not updated: store visibility, push delivery, OS changes. This is the same decay seen from the server side. An allowlist moves, and every build older than that date loses a capability, without a crash and without a line in the phone's log.

What I check first now

Is the half that works real? Before comparing a GET and a POST, find out whether the GET's data came from the network. Search the page for catch. If a model wrote the code, expect a fallback: models are polite about failure, they fill the hole.
One trace from the failing device. Web Inspector or chrome://inspect, five minutes. It would have shown no request to the proxy at all, neither GET nor POST, and a refused frame in the console.
The build date of the shell, before any server log, whenever the report says "fine on the web, broken in the app". Then compare it with the dates your allowlists changed.
Substitution, last. The same bundle on a fresh shell proves where the fault is not, and says nothing about what happened on the old one. "Works on the simulator I built this morning" and "works on the phone in my pocket" are different claims. That gap is where a correct fix picked up an invented cause.

The model's fallback stays. A quote widget that shows a default quote instead of a broken box is the right behaviour for the person using the app; it is only a trap for the person debugging it. So its firing becomes visible:

.catch(function (err) {
  console.warn("[quote] proxy call failed:", err.kind, err.message);   // the line that was missing
  showFallbackQuote();
})

With that line, the first look at the console says init, no token, before anyone opens Xcode. Degrade gracefully for the user, loudly for the developer.

After the migration

https://secure.internal is shared across our apps, just as appassets.androidplatform.net is shared by Android apps using that loader. It gives browser policies a stable value to compare. Authentication still needs its own mechanism, which is what the token is for.

The practical gain is that local content gets ordinary HTTPS behaviour while staying available offline. The cost sits in everything attached to the previous origin: storage, remote allowlists, and the builds already installed. That is why the new name is boring, fixed, and meant to stay. Changing it later is another migration, even if every HTML file stays the same, and the phones in people's pockets will not follow.

The assistant is making the native app mandatory again

Mathieu Poli — Thu, 01 Oct 2026 07:25:35 +0000

For ten years, a well-built website was an acceptable answer to the question "do I need an app?". This year, Apple and Google settled how the phone's assistant will act for us, and that answer no longer quite holds. The app is becoming an entry ticket again, and not for the reasons of 2008.

My colleague Dominique Siacci explained at the end of September why agents won't kill apps: on a phone, they can't act without them, because the app already carries the identity, the rights and the relationship an agent needs. I'd like to draw the consequence for the question we've been asked for fifteen years, and which is changing its answer for the third time.

Three answers to the same question

I've been building app platforms since 2011, and I've watched the answer to "do I need an app?" change twice.

The first answer was yes, no discussion. Between 2008 and 2014, being on the home screen meant existing. An icon on the phone was worth a shop window downtown. That rush is what gave birth to GoodBarber, and to dozens of tools like it.

Then the web took back control. Progressive Web Apps, Google pushing the browser as a platform, and a decade of "you don't need an app, a website is enough". The argument was solid. So solid that we added a PWA engine next to our native engines, in 2017, and we still sell it. One project description, three outputs: Swift, Kotlin, and the web. When I say the app had become optional, I say it as someone who built the option.

The third answer is taking shape this year.

What changed this year

At WWDC in June, Apple made App Intents the door through which Siri gets into third-party apps, and deprecated the old mechanism, SiriKit. iOS 27, released on September 14, launched a new Siri meant to act and search inside apps from a single sentence. It's early days. According to Apple, it's in beta and English first. It isn't available on iPhones in the European Union, and actions in third-party apps are coming "soon". Android is heading the same way with AppFunctions, shipped in Android 16 and still in beta with Gemini. Dominique covers the mechanism, so I won't go over it again.

The door itself isn't new: App Intents have existed since 2022. What changes this year is that Apple makes it the standard way in, and that the assistant will walk through it on its own, from a sentence.

For the question of this article, one thing matters: both mechanisms are native development kits, built into an app's binary, and a web page can't register with them. There is work on the web side, WebMCP, but it targets agents running in the browser, on an open page. The phone's assistant only looks at what's installed. I'm not saying anything about adoption, which nobody knows, or about when everyone will get access. I'm saying the entry ticket is defined, by both platforms, the same way.

Why this isn't 2008

It's tempting to read this as a step back.

In 2008, having an app was about capturing attention: an icon on the home screen, notifications. The app was a shop window. Tomorrow, having an app will be about being present in the assistant: when someone says "get me a seat for Saturday's concert", it's your app or someone else's that answers. The first was won with design and marketing. The second is won by describing your app, what it does as well as what it holds, precisely enough for a machine to use it.

There's a condition, and Dominique puts it himself on his list of what would prove him wrong: the assistant only calls what's installed. To be present in the assistant, you first have to be installed, and that's exactly the 2008 problem: the shop window is still the prerequisite.

This isn't the story I told in September either. There, I was talking about the cost of building: coding agents make it cheap to build the same app three times. Here, it's about distribution: who gets to be in the assistant. Two different mechanisms, pushing in the same direction.

So, do you need an app in 2026?

The question "do I need an app?" has had one answer per era. Yes, to be seen. No, a website is enough. And now: if you want to exist, one way or another, in the phone's assistant, yes.

First, to act. Booking a class, ordering, tracking a delivery, moving an appointment: these are exactly the sentences people will say to the assistant, and it can only carry them out in a native app that has declared those actions.

But also to be found. The assistant searches as much as it acts. When someone asks it to "find me a concert in Ajaccio next weekend", it will look in the content that installed apps have described to it: Apple explicitly plans for Siri to answer questions about an app's content. It's already what apps built on GoodBarber do when you ask Siri "what's new?", from iOS 17, without their owners having to touch anything. The rollout happens in stages, and my colleague João Aleixo explains how on our blog. A cultural events calendar or a local news outlet has as much to gain as a booking app.

And the assistant doesn't only live in the phone. In the car, few apps get a place on the CarPlay screen: Apple reserves it for a few categories, navigation or audio for instance, and rebuilding an interface for the dashboard rarely makes sense. But Siri is in the car, and an app that has declared its actions can answer there by voice.

The website keeps its role: it's what people find on Google, and it's what welcomes the visitor who comes once and won't install anything. We still sell PWAs, and many projects will have both: the website for Google, the app for the assistant.

It isn't urgent. If your users are in Europe, the new Siri hasn't reached them yet, and I don't know when it will. But the entry ticket is already set, and it's a native app.

The web had made the app optional. The assistant is making it mandatory for anyone who wants to be within earshot.

Mathieu Poli, Head of Frontend Engineering @ GoodBarber. I teach and write about frontend engineering, product design, and AI, and everything that happens when the three meet.
X: hellomathieup · LinkedIn: hellomathieup

Agents won't kill apps... on a phone, they can't act without them

Dominique Siacci — Tue, 29 Sep 2026 07:08:15 +0000

At WWDC this year, in the keynote, Apple confirmed something I had been holding as a logical intuition more than as an open question: when the assistant that lives in your phone wants to do something for you, it goes into the apps installed on that phone. An app declares the actions it can perform, and that is what Siri calls. On Android, Google is building the same door under the name AppFunctions, and describes it in its own documentation as the on-device equivalent of the tools an agent calls over MCP.

Two operating systems, the same year, the same decision. Meanwhile what you keep reading in 2026 is that apps are on their way out.

Where I'm standing

I am a co-founder of GoodBarber, a platform that builds and publishes mobile apps, where I run engineering and a little bit of everything. So a piece by me arguing that apps have a future deserves the suspicion you'd give a baker writing about bread. Read it that way. Further down I list what would prove me wrong, and I'll come back with numbers when we have them.

The case against apps, taken seriously

Carl Pei, the CEO of Nothing, said it plainly at SXSW this spring: apps are going to disappear. The argument is coherent. An agent doesn't need a screen to order a pizza; it needs an endpoint. If it can reach your service through an API or a website, the app in between is a detour, and a company's real product becomes the surface its agents can call.

I believe half of it. Agents do remove navigation: nobody wants to tap through four screens when a sentence does the job. A clean, documented surface matters more than it ever did. And we run one ourselves: a production MCP server that agents call all day to manage apps, without opening a single one of them.

The disagreement is about where the agent goes when the user is holding a phone.

What I think, and I'll own it

Apple clearly wants everything the assistant in your phone does, in what they now call your intelligent personal hub, to go through the apps installed on it. And I think they're right. It's the most logical channel there is.

Not because apps are nice, or because I sell them. Because on a phone, the app is the one place where three things already exist together: an identity, a set of rights, and a relationship. Everything an agent would have to rebuild from scratch on the web is already sitting there.

The door

On a phone, the assistant doesn't browse. It calls what an app has declared. The shape is familiar if you've written tools for an agent: a name, typed parameters, a description the model reads, a result it can show or speak. The difference is that the tool lives inside an installed app, with the app's data and the app's rights, and the operating system is the one dispatching the call.

If your service isn't installed, it isn't a tool. The assistant can't find it, can't ask it anything, can't act through it. That is a hard line, and both platforms drew it on purpose.

The rights

Think about what an agent needs before it can do anything useful for a person: who they are, what they've paid for, what they've allowed, how to reach them. On the web, every one of those is a login, a consent screen, a token, a form. In an installed app, all of it already exists. The session is open. The subscription is active. The notification permission was granted months ago. The agent inherits all of it the moment it goes through the app, and it can't do more than the user could, because an interface inherits the rights of whoever it acts for.

This is why I don't think the app's role shrinks as agents get better. An agent that can act on your behalf is worth exactly as much as the rights it can act with, and those rights live in apps.

The interface

Here is where I go a step further. I think the assistant is going to be the natural way to use an app, on the phone. You say what you want; the assistant asks the app; the app answers, in the assistant, with a card, a list, a confirmation. The screens stay for what a screen does better than a sentence, comparing, browsing, checking. I wrote about an agent as the first interface you don't have to learn from the operator's side; this is the same idea reaching the person who uses the app.

And I don't think it stops at Siri. An assistant that belongs to the app itself, that answers from its content and acts within its rights, is a second way in, next to the screens, not instead of them.

Two doors, one rule

From where we sit, an app now has two doors for agents, and they don't lead to the same room. Its owner's agent talks to the server that manages the app: content, products, notifications, the things an owner does. The phone's assistant talks to the installed app itself: the things a user does. Two doors, two sides of the product, and one rule that holds on both: each door inherits the rights of whoever it acts for, the owner on one side, the user on the other.

Our engine already answers one question from Siri, "what's new", and it is reaching apps in stages. The real work is ahead, and it has a shape of its own: we don't write one app, we publish thousands from the same engine, each described by its own configuration. So what an assistant can do in an app is something we define the way we define a feature: once, in the engine, as an opening, and every app that has the feature gets it.

What would prove me wrong

I want this list to be checkable, so here it is.

The assistants route around the apps. If in two years Siri and Gemini reach most services through the web or through APIs without an installed app, and the platforms let them, the door I'm describing was a phase.
Nobody installs. If assistants don't bring people to install anything, and the only apps worth calling are the ten everyone already has, this thesis holds for the giants and for nobody else.
The door stays half-open. If third-party actions stay a demo feature, reserved for a few partners, the mechanism exists and doesn't matter.

If you ship an app: what did you expose to Siri or Gemini first for this release, and what did you decide to keep behind a screen?

Our tools are built for humans, not for agents

Mathieu Poli — Wed, 23 Sep 2026 07:20:37 +0000

You don’t need to believe AI thinks to anthropomorphize it. Handing it our tools is enough. GitHub, the pull request, code review, Scrum, the sprint, the standup, everything that organizes the work of a development team was designed to coordinate humans, and since agents started writing code, we’ve been handing all of it to them as is.

The frontend team I work in, at GoodBarber, started out adapting that way, then realized fairly quickly it was a mistake and changed course. What I take from it, personally, is that the tooling has to be redefined for machines, not adapted from ours.

Our tools are tools for humans

The standup exists so that people working side by side don’t each drift off in their own direction. The sprint bounds time because we always overestimate what we’ll ship in two weeks. The pull request keeps a record of a choice its author will have forgotten in a month, and code review puts a second pair of eyes where the first no longer sees anything.

None of these tools is about code. They compensate for the flaws of people, and they were tuned, over twenty-five years, to the speed at which people work. A Medium post titled “Built for Humans”, published in June 2026, says it in one sentence: these processes were calibrated on us.

Anthropomorphism, at industry scale

When AI coding agents arrived, we built nothing for them. An agent opens a branch, pushes commits, writes its pull request, answers the reviewer’s comments, and nobody found that strange.

A study from NAIST, published on February 19, 2026, on 33,596 pull requests opened by five agents, shows how far it has gone: depending on how the agent writes its description, humans answer it faster or slower and accept its code more or less often. We are grading a machine’s manners on a form written for colleagues.

In the other direction, a session at Stanford on April 30, 2026 proposed managing agents with Scrum and Kanban, standups included, to give them the memory and coordination they lack.

In July 2026, Kyle Galbraith of Depot wrote that GitHub is the wrong shape for this new world. His subject was infrastructure. I replied that the problem looked wider to me: Scrum, PRs, sprints all coordinate humans, and we keep anthropomorphizing AI by handing it our rituals.

Anthropomorphizing, here, means giving the machine a process designed for someone who forgets and gets tired, without having checked what that process was protecting us from.

Do pull requests work for AI agents?

Yes, they work, and that’s the trap. An agent knows how to open a PR, describe it and answer a comment. The ritual accepts it without blinking, so we keep the ritual and try to adapt inside it.

That’s what we did at GoodBarber. Before agents, the pull request was already our bottleneck. Code waited for a reviewer longer than it had taken to write. With agents, the number of pull requests exploded, our reading capacity stayed the same, and review delays started being counted in weeks. We spent our days reading code written by a machine, never catching up with the queue.

The Faros AI report of April 2026, on 22,000 developers, counts 67.4% more pull requests to handle per developer per day, so there is nothing local about it.

Reading all that code, I understood that review rested on an assumption we had never had to state: the author will be there tomorrow. They will remember why they made that choice, and they will own the bug if there is one. The whole conversation around a PR rests on that. An agent closes its session and its context is gone.

A January 2026 study of 33,707 agent-authored pull requests, picked up by Addy Osmani, sees it in the data: agents merge small, well-scoped changes fast, and disappear the moment they get subjective feedback.
The pull request assumes an author who will come back. The agent doesn’t come back.

We didn’t manage to adapt review. We removed it. In the spring of 2026 it stopped being mandatory on more and more pull requests, starting with the changes we knew how to undo, the line I described in my piece on the net. As of September 2026, it only remains on changes rated critical, the ones whose release is risky. Everything else goes through a pull request loop between agents, and ships without a human having read the diff.

The first weeks were stressful, I won’t pretend otherwise. But the productivity gain is such that we can afford to handle the misses, provided we assessed beforehand that the risk stayed contained.

Scrum went the same way, only more abruptly. A two-week sprint is tuned to one person’s throughput, and once execution moves to agents, the sprint is empty long before it ends. The “Built for Humans” post tells it as a scene: two weeks of work finished by Tuesday. What limits the team now is what it can specify and verify, and Scrum has no tool to measure that.

At the September 2026 rentrée, we used the calendar to drop our human-designed methods all at once. We’re trying other ways of working right now, and I don’t have a method to recommend yet.

What a tool for machines needs

What’s missing is the tooling that comes next. Bryan Finster published in July 2026 the experiment that gave me my diagnostic. He had agents run the same tasks with and without our disciplines: TDD, pair programming, separating author and reviewer. His result: refactoring improves the code, writing the test first changes nothing. “Refactoring is the mechanism. Test-first ordering is the ceremony.”

The mechanism serves the machine. The ceremony served the human who had to force himself to think before writing. The ceremony is the human part of the tool, and it’s exactly what we hand the agent when we anthropomorphize.

From there, we can say what a tool designed for a machine looks like, because we already know its properties in the negative.

It asks nobody to be present while the machine works, whereas a ritual rests entirely on presence.

It draws the line between what the agent executes and what it proposes on the reversibility of the mistake, not on how confident the model sounds.

It gives the agent a written context it reads before starting, in place of a meeting where someone recites it.
And it verifies at the machine’s production speed, not at a human’s reading speed.

We had to design such a tool, on a small scale, because we had no choice. When AI writes code for someone who isn’t a developer, inside our product, that person has no pull request, no sprint, no reviewer. There was no ritual to lend it.

What we wrote looks like none of our meetings: a line drawn on reversibility, and an access surface declared up front and checked server-side, a choice my CTO Dominique has written about. It’s not much, but it’s designed for the machine, and it was easier to find there than in my own team, where we had a ritual within reach.

The tooling has to be rebuilt

My position is that the next generation of development tools has to be defined for machines, not adapted from ours. A faster pull request or an automated standup keep the human shape, and the human shape is the problem.

We’ll need tools that carry context so nobody has to remember it, that bound damage rather than time, and that verify at the pace the machine produces. I don’t know yet what they will look like. I’m wary of those who already do, they usually sell one.

It’s the same conclusion I reached about frameworks: when producing gets cheap, what holds value is what remains underneath, and for a team that’s the tooling.

If you’re adapting your team to AI, look at what you’re handing it. If it’s a pull request, a sprint and a standup, you’re not adapting to AI. You’re teaching it to pretend to be one of your colleagues.

Our tools compensate for our flaws. Before handing one to a machine, ask whether it has the flaw.

Mathieu Poli — Head of Frontend Engineering @ GoodBarber. I teach and write about frontend engineering, product design, and AI, and everything that happens when the three meet.
X: @hellomathieup · LinkedIn: hellomathieup

Cover photo by nikohoshi on Unsplash.

Listing a remote MCP server in every directory: what each one actually checks (September 2026)

Pierre-Laurent Medori — Thu, 17 Sep 2026 11:52:00 +0000

The Save button did nothing. We opened the network panel. The request had returned HTTP 200.

Inside the response: a validation error on a field the form did not show.

By then we had spent several days trying to get the same remote MCP server listed across directories. Another directory had published us in about ten minutes. A GitHub list had tested our endpoint and accepted its 401. Elsewhere, our submission was waiting for a human.

"Get the server listed" had turned into a collection of different jobs.

One line of context so you know where I stand: I run engineering at GoodBarber, an app platform, and our MCP server lets assistants manage the apps through an authenticated connection. It is hosted, it requires OAuth, and there is no public server code for a directory to scan: our public repository holds skills and client configuration. That distinction decided which submission paths worked.

After getting the server into ChatGPT's plugin directory, we widened the search. What follows happened between September 7 and 14, and every public state was checked again on September 14. The delays are the ones our submissions went through, not a promise from anyone.

The official MCP Registry: publish the identity first

The official MCP Registry accepts metadata for hosted servers, closed-source implementations included, as long as the server is publicly reachable. It authenticates the publisher's namespace and validates the metadata. Beyond that, its metadata is deliberately unopinionated, and curation is left to the aggregators downstream.

Our entry, dev.goodbarber/goodbarber-public-mcp, has been there since April 28 (version 1.0.0). On September 7 we published version 1.2.1, with DNS authentication: it declares streamable-http, the remote endpoint and the product page. On September 14 the registry API still marked it active and latest.

We would do this first again. It gives importers a stable identity and a record to consume, instead of asking each directory to rebuild the product from a README.

Glama had already imported a connector entry from that record. We claimed it, and on September 8 it displayed "Ownership verified" and "Healthy". Both were still there on September 14.

Upstream publication does not tell you when the downstream pages will exist. MCP.Directory says it auto-discovers servers from the official registry, where our entry has been since April. Its submission form promises a review within 24 hours, and its first, required field is a GitHub repository, from which it detects the tools by analyzing the server's implementation. The Knights Who Say Ni wanted a shrubbery; a hosted server with no public code has no repository to give. On September 14, MCP.Directory's sitemap still had no GoodBarber URL, six days after a server listing request and five skill submissions. Where those submissions sit, we do not know.

awesome-remote-mcp-servers: the CI that accepts a 401

awesome-remote-mcp-servers is built for our shape of product. It only lists servers the provider hosts: reachable at a public URL, usable by anyone who can sign up, speaking Streamable HTTP or SSE. Each entry's name links to the product's homepage, not to a GitHub repository, because the endpoint is the thing being listed. The list was created on September 8, and our PR went in the same morning.

It also gave us something we could test. Its submission workflow at the merge commit probes each endpoint with a real initialize handshake and sends no credentials. We replayed the check before submitting. Our endpoint answered with an authentication challenge, structurally like this (generic domain):

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"

The workflow takes a 401 or a 403 as a live endpoint that requires authentication, and reads the WWW-Authenticate header to choose between the OAuth and API-key markers. Our 401 passed with the OAuth marker. The probe never completes OAuth and never calls a tool: a green check here means the door exists.

Two more rules matter before you open the PR. Every entry needs a Glama connector badge, and CI checks that the connector exists. And the contribution rules document a fast track for automated agents: three robot emoji at the end of the PR title. Our PR was prepared by an agent, so we used it. PR #4 was opened at 07:23 UTC, labeled endpoint-ok and has-connector by CI nine seconds later, and merged at 13:50 UTC, on September 8.

Then the bot ran again on the merged PR. It added duplicate and missing-connector, removed has-connector, and asked us to remove the duplicate entry. The duplicate was ours: the check was now reading the list it had just merged. The README on the main branch settled what the labels could not.

Gemini CLI and GitHub: a crawler versus a review queue

The Gemini CLI gallery instructions describe a daily crawl of public GitHub repositories carrying the gemini-cli-extension topic. A gemini-extension.json manifest at the root of the repository supplies the metadata, and an extension appears in the gallery only if it passes validation. The instructions say there is no issue to file and no email to send.

We added the topic on September 9. On September 14 the topic and the manifest were in place, and the gallery page had no GoodBarber entry. A daily crawl gives no per-repository result, so we cannot tell whether we failed validation or were never picked up.

GitHub's MCP gallery has another gate. In discussion #1257, a GitHub answer explains that onboarding a new server is a manual curation process, and that new registry versions sync once a server has been onboarded. We asked to be included on September 8; on September 14 the expected gallery URL still returned 404. Republishing the registry record would change nothing there.

Our Claude Code plugin sits in a similar waiting room. Plugins are submitted through a form, and the public community marketplace catalogue is a read-only mirror, synced nightly from Anthropic's review pipeline, of the plugins that passed automated security scanning and were approved. Ours was submitted on September 7, shown as awaiting review on September 8, and still absent from that catalogue on September 14.

Claude connectors: ten minutes, then an inventory problem

The Claude connectors directory is a different destination from the Claude Code plugin marketplace. Remote servers are submitted from an organization's admin settings, through a portal that connects to the server. Our connector listing appeared about ten minutes after we submitted it on September 8, while the plugin was still waiting. Its tier is community, and that is the word we use.

Then we read the published inventory and found our own mistake. The directory's public record listed 120 tool names and left out an entire tool family, the one behind push notifications and analytics, while the description we wrote advertised both. The portal syncs the tool list from the server through the connection made at submission, and our connection did not expose that family. The description is ours to edit from the dashboard; the tool list is not an editable field, and changing it goes through the review team. Either way, the fix is ours.

For someone following the Claude connection guide, the only question that matters is whether the tools they get cover the task they came for. A directory listing does not change the tools a connection exposes, so the check we owe that reader goes beyond the listing: the published inventory against the description, then a real connection.

mcp.so: HTTP 200, application-level failure

The Save button from the opening was on mcp.so. We were updating an existing listing whose transport and overview had gone stale.

On September 8 the edit request returned HTTP 200, and its body carried application code -1, an "Invalid submission" message and a validation error under fieldErrors.tagline. The old tagline was too long. The form had no field to fix it and showed no error.

We sent the edit again with a shorter tagline, then read the public page, because a save response is a claim, not a result. On September 14 the listing showed Streamable HTTP, OAuth and the updated overview.

If that sounds familiar, it is the write-safety piece in miniature, with a web form in place of an agent. The green request in the network panel meant an HTTP exchange had completed, nothing more. Read the body, then read the page.

MCP Market: fast, paid, and one button to check

On September 8 we paid $69 for the remote-server "Official" listing option, which is a different product from the GitHub-repository submission. The listing was live the next morning, inside the advertised 24 hours, with the badge and the categories we asked for.

Search MCP Market for GoodBarber and a second card shows up next to ours: GoodBarber Skills, filed under Marketing Automation.

Then we clicked Try Now.

We had submitted our MCP product page as the destination. The published button led to our app-creation page, with MCP Market campaign parameters added, and still did on September 14. Both pages are ours, and it matters anyway: someone looking for connection instructions lands on a different step of the product journey.

Paying got the listing published fast. Checking where it sends people stayed our job.

Smithery and skills.sh: read what the signal measures

On Smithery, verification happens in the server's settings, through what its publishing guide calls an automatic official-vendor verification checklist. Our domain and backlink proofs passed their recheck on September 8. The public data embedded in the listing page said verified: false afterwards, and still did on September 14. The guide names the checklist without listing its items, and nothing we could see explains the step between two passed proofs and a false flag. We write down both states rather than calling the whole thing verified.

skills.sh showed our 44 skills on September 14, with installation counts. There is nothing to submit there: skills appear through the anonymous install telemetry of its CLI, when people run npx skills add. Those skills are instruction packages for using the server, and the counter measures installs: not a completed workflow, and not an OAuth flow that works in every client.

The September 14 snapshot

Every state below was checked on September 14, 2026; submission and publication dates are the real ones. Read "pending" as pending, and "absent" as unexplained.

Directory or catalogue	Admission mechanism	Observed delay	State on September 14	Pitfall
Official MCP Registry	Namespace authentication, metadata validation	Entry since April 28; 1.2.1 on September 7	Version 1.2.1 active and latest	Curation is left to aggregators
Glama	Registry import, ownership claim, health checks	Initial import not timed	Ownership verified; Healthy	Ownership and health are separate signals
awesome-remote-mcp-servers	Endpoint CI without credentials, Glama connector badge, PR	Same day, September 8	PR #4 merged	The probe stops at the 401
MCP.Directory	Registry auto-discovery; GitHub-based form with a 24-hour review promise	September 8 to 14, unresolved	No GoodBarber URL in sitemap	The form expects a GitHub repository
Gemini CLI gallery	Topic crawl, root manifest, validation	September 9 to 14, unresolved	No entry on the gallery page	A daily crawl gives no per-repo result
GitHub MCP gallery	Manual curation, then version sync	September 8 to 14, unresolved	Expected URL returns 404	Registry publication does not grant admission
Claude Code community marketplace	Submission form, security scan, approval, nightly mirror	September 7 to 14, unpublished	Absent from public catalogue	Separate from the connectors directory
Claude connectors directory	Admin portal; tools synced from the connected server	About 10 minutes, September 8	Community listing; 120 declared tools, no push or analytics	The synced tools did not match our description
mcp.so	Authenticated form and API validation	Update completed September 8	Corrected transport and overview live	HTTP 200 carried a validation failure
MCP Market	Paid remote-server submission	Live the next morning, September 9	Official listing live; a GoodBarber Skills card also listed	Try Now destination changed
Smithery	Official-vendor verification checklist	Proofs passed September 8	Public data still says `verified: false`	Passed proofs did not flip the public flag
skills.sh	No submission; CLI install telemetry	First install not timed	44 skills listed	Installs are not workflow success
Docker MCP Catalog	Remote-server PR, Docker team review, test credentials by form	Open since September 8	PR #4968 open; 0 comments	Review outcome unknown
VoltAgent skills list	Skills-list PR; rules require real community usage	September 8 to 14	PR #1031 closed without merge or comment	Adoption comes before the listing
BehiSecc skills list	Skills-list PR	Open since September 8	PR #689 open; 0 comments	Skills listings have their own review
Cline marketplace	Submission issue; review of adoption, credibility, maturity, security	Open since September 9	Issue #2492 open; 0 comments	Review weighs community adoption

The order we would follow next time

Start with the official registry, and with one description, one endpoint, one product page and one documentation URL, the same everywhere. Separate the hosted server from the skills package before choosing routes: some submission forms start with a GitHub repository, and a hosted server has nothing to put in that field.

Then read each gate before you submit. Replay public CI checks. If an agent prepares the PR, use the documented agent fast track. For a crawler, check the topic and the manifest. For a curated catalogue, read the acceptance criteria first, since some weigh community adoption, then keep the submission reference and wait for evidence of admission.

After publication, read what went live: the tool inventory, the authentication metadata, every destination link. Keep dates next to results and recheck weekly. The merged PR, the badge and the live page can tell three different stories.

All of it points to one page, the connection guide. If you are connecting GoodBarber to an assistant, start there.

One more thing: that was a dense week, and these procedures move fast. What you read above comes from each directory's own documentation where it has one, and from what we saw on the forms otherwise, checked on September 14. If you run one of these directories and something here is wrong, or already out of date, tell us in the comments.

Which check caught a mismatch in your own listing: the response body, the tool inventory, or the link after publication? Genuinely curious.

The URL on the flyer doesn't know your app changed

Dominique Siacci — Tue, 15 Sep 2026 14:29:50 +0000

A link leaves your system the moment it's printed. The QR code on a restaurant's counter card, the URL at the bottom of a club's poster, the link a shop put on its packaging three seasons ago — none of these can be recalled. You can't redirect ink. Whoever scans that code has an appointment with your app, and they chose the date: maybe this afternoon, maybe in four years, long after the app was redesigned twice and the section it pointed to was renamed.

A link is a promise. And the inconvenient part of the promise is that its duration was never yours to choose.

One door, many keys

Links reach an app from more places than anyone plans for: a QR code, a push notification, a URL shared in a chat, a link inside the app's own pages, another app handing over an address. Every one of those arrives shaped differently.

Our answer is architectural: all of them funnel into a single resolver. Whatever the source, the link is first translated into the same internal representation — what is being asked for, in which section — and only then does anything happen. The variety of doors is a parsing problem at the edge; behind the edge there's one door, and one promise to keep.

Formats get added. They don't get retired.

Over the years, the shape of our links has changed — of course it has: URLs got cleaner, more readable, more shareable. Each generation was an improvement, and each one created the same obligation: every link emitted in the old shape was already out in the world, printed and pinned and bookmarked.

So the rule is simple and it only goes one direction: formats get added, never retired. A link built the way we built them years ago still resolves in the app that ships today — not because that old parsing code is anyone's pride, but because the alternative is breaking a promise someone else is still holding. Backward compatibility of this kind isn't a feature you announce; it's debt you carry with a straight face, because the person who scanned yesterday's format doesn't know it's yesterday's, and shouldn't have to.

Durable by construction

Honoring old links forever would be impossible if a link depended on things that change. So the durability is built into the addressing, not into a policy of never changing anything.

A link targets a section by a stable identifier — never by its position in a menu. Reorder the navigation, redesign every screen: the identifier doesn't move, so the link doesn't care. Renamed a section's public URL? Where the platform can, the old slug is absorbed by a permanent redirect to the new one. Even the domain gets the benefit of the doubt: a link is matched with and without www, in http as well as https — so a flyer printed back when the web still said http:// opens today's app without noticing what decade it is. None of these tricks is clever on its own; it's the ordinary toolbox of URL hygiene. The only discipline is in refusing to skip any of it, anywhere, ever.

The pattern behind all of it: everything around an app changes over three years — the design, the structure, the web's own defaults. The address layer is built so that nothing a link relies on is among the things that changed.

When the promise can't be kept

Sometimes resolution genuinely fails — the section is gone, the content deleted. What happens next depends on where the link came from, and the distinction matters.

Inside the app, a link that resolves to nothing is a bug, and it gets treated like one: a not-found screen, visible enough that someone fixes it.

But a link arriving from the outside world — the flyer, the QR in the street — never ends on a dead end. As a last resort, when every attempt at resolution has failed, the visitor lands on the app's home. Not because errors should be hidden, but because of who's standing there: this person didn't hit a bug, they exercised an old promise. Handing them an error page punishes them for our history. Handing them the home screen at least honors the half of the promise that's left — there is an app here, and you're welcome in it.

You don't control when a link will be redeemed. You only control whether, on that day, it's honored. Build for the second, because the first was never up to you.

"Too many levels of symbolic links" with no symlink in sight: autofs, a bind mount and a cron container

Pierre-Laurent Medori — Tue, 15 Sep 2026 11:54:39 +0000

In September, our PHP crons started failing with an error that sounded specific:

Too many levels of symbolic links

That is ELOOP, the error a symlink loop gives you, so the first move was to look for a loop on /srv/apps/app-a/task.php. There was no symlink on that path. Nothing to untangle.

Paths and component names below are generic examples, not ours.

By the time we looked again, on September 10, the file was readable. The autofs service had just restarted, and the same file answered on /opt/code/app-a/task.php and on /srv/apps/app-a/task.php. That left a question the successful ls could not answer: what had to work for the second path to reach the first?

For context: I run engineering at GoodBarber, an app platform, and these crons run its background jobs. The short version of what follows: the code was already bind-mounted into the container, the paths the crons used still went through autofs, so we mounted the code directly at those paths and took them out of the automount map. If ELOOP sends you hunting for symlinks that are not there, look at your automounts, and at what the container's mount namespace can actually see.

The autofs layer inside Docker

The cron container's Compose configuration already mounted the application code from the host:

host /srv/code/app-a -> container /opt/code/app-a
host /srv/code/app-b -> container /opt/code/app-b

The application expects /srv/apps/app-a and /srv/apps/app-b. The image supplied those two paths through an autofs direct map:

# /etc/auto.master
/- /etc/auto.apps --ghost,--timeout=30

# Two entries in /etc/auto.apps
/srv/apps/app-a -fstype=bind :/opt/code/app-a
/srv/apps/app-b -fstype=bind :/opt/code/app-b

Any access to either path could trigger the automounter. The other entries in that map were NFS shares, managed by the same daemon.

Two layers of mounting for code that was already local. Opening a PHP file depended on the service that manages our network mounts.

Why an automount can return ELOOP

The error name is narrower than the mechanism behind it. In Linux v6.1, follow_automount() increments nd->total_link_count, the same counter symlink traversal spends, and returns -ELOOP once it reaches MAXSYMLINKS, which is 40. During a path lookup, every automount crossed counts against the symlink limit. No symlink required.

The autofs documentation describes the other half. When an autofs filesystem is visible in several places and the mounts created by its daemon do not propagate to the others, access from those other places "will likely result in the ELOOP error". The caller keeps meeting a trigger and never sees the mount it is waiting for.

That is how you get ELOOP without a symlink. Which of the two our incident took, we cannot say: the investigation tied the failure to an NFS incident and an unhealthy automounter, and we did not capture a kernel trace. What the configuration did show is the dependency itself, and it had no reason to exist, whatever upset the daemon first.

The fix stayed in configuration

On September 10 we added direct Docker binds at the paths the crons actually use. The relevant Compose fragment:

volumes:
  - type: bind
    source: /srv/code/app-a
    target: /srv/apps/app-a
  - type: bind
    source: /srv/code/app-b
    target: /srv/apps/app-b

We also gave the cron container its own copy of the automount map, with those two entries removed. It takes both changes: leave the keys in the map and autofs installs its triggers over the direct mounts again.

One detail of our image: the map path, shown here as /etc/auto.apps, is a symlink to the real map file. The Compose override mounts the cron-specific map over that target. The web containers keep the map they had.

The application teams maintain and deploy that code. This was an operations fix, so it stayed in the mount configuration and the application paths did not move. No PHP patch, no local checkout drifting away from what the application teams deploy.

Proving the dependency is gone

Roy from The IT Crowd has a suggestion: "Have you tried turning it off and on again?" We already had a readable file after a restart. The useful test was whether it still needed the automounter.

Inside the cron container, check each mount on its own:

findmnt -o TARGET,SOURCE,FSTYPE /srv/apps/app-a
findmnt -o TARGET,SOURCE,FSTYPE /srv/apps/app-b
grep -cE '^/srv/apps/app-(a|b)[[:space:]]' /etc/auto.apps

Both mounts should resolve to the host-backed code, with no autofs trigger underneath. The count should be 0, and grep exits with status 1 when nothing matches. If mounts are stacked, read /proc/self/mountinfo as well: the filesystem on top hides what sits below it.

Then check the cron runs after the deployment. The jobs have to actually run, and their new logs have to be free of ELOOP. Silence from a job that never started proves nothing.

The deployment was confirmed working on September 10. One check we have not run yet: in a maintenance window, with the NFS-dependent jobs paused, stop autofs inside the cron container, read the PHP entry point, then restart autofs and confirm it is active. The direct bind should stay readable. That tests the dependency removal, not an NFS hang.

The maintenance we kept

We now have two maps, and any change to their shared NFS entries has to land in both. Removing a runtime dependency left us a configuration chore.

The code was local all along. We changed how the crons reach it, and opening a local PHP file no longer needs the automounter to cooperate.

Have you met ELOOP with no symlink in sight? What was underneath on your side: autofs, a bind mount, something stranger? Genuinely curious.

Everyone is going back to native. We never left, and the bet paid in a way we didn't expect

Mathieu Poli — Fri, 11 Sep 2026 11:45:22 +0000

You've probably read it by now: Shopify is moving all of its mobile apps back to Swift and Kotlin, six years after going all-in on React Native. In their own words, "building the same feature in Swift and Kotlin no longer carries the cost it used to," because coding agents now do enough of the work in between. We never left, and I want to be precise about why. We bet on native in 2011 for one reason: iOS and Android would outlive every layer stacked on top of them. Every layer since has been temporary, which we expected. What ended the detour was AI, which we didn't.

We bet on native because it was the layer that would last

When people ask why an app builder compiles Swift and Kotlin instead of shipping one cross-platform codebase, they expect an answer about quality, and the honest answer is about time. In 2011 we had to decide what to build our engines on, knowing we'd carry that choice for a decade or more, so the question we asked was which layer would still be there in ten years.
The platforms would. Apple and Google were not going to abandon their operating systems, their toolchains or their SDKs. Everything in between, the frameworks promising to spare you the platforms, had to earn a decade of existence, and nothing about them suggested they would. So we invested in the layer that was certain to remain, and we treated everything stacked on it as temporary, however popular it was that year. That's the whole bet. It cost us more per feature, and it bought us a foundation we have never had to rewrite because a dependency died underneath it.

Every layer since has been temporary

The waves came on schedule, roughly one every few years, and each was presented to us as our replacement. 2011: PhoneGap, bought by Adobe that year, and the first serious promise of one web codebase for every platform. 2015: React Native. 2016: Xamarin, bought by Microsoft, and the promise of C# everywhere. 2018: Flutter 1.0. We evaluated two of them seriously, React Native a couple of years after it shipped and Flutter once it had matured, and both times the same question decided it: what's the lifespan of this layer, compared with the lifespan of what's underneath?
Then the answers arrived. Adobe discontinued PhoneGap in 2020. Microsoft ended Xamarin support in 2024. And this year Shopify, which had bet on the most successful of those layers, announced its way back to the platforms. The intermediate layer kept changing names while iOS and Android kept theirs. None of that makes the people who chose those frameworks wrong: for a company shipping one app, avoiding a second codebase was a rational bet, and I'd have made it in their seat. It's just a bet on a shorter horizon than ours.

Why we could afford a bet nobody else could

What made our choice possible is simpler than vision, and I'd rather state it plainly. An app builder doesn't build one app; it builds engines that render thousands. At GoodBarber, our iOS engine is Swift, our Android engine is Kotlin, and a third engine produces a Progressive Web App; a single project description feeds all three. We build three times, but we build three times once, and every app the platform renders amortizes those three engines a little more. The duplication cost that pushed the industry toward hybrid, divided by thousands of apps, was simply our business model. The reason to leave native never existed on our side of the fence.
The bill is real, though. Three engines mean three expertises to hire and three implementations to keep in step, and the parity work between platforms is a permanent line in our budget. It's payable for one reason only: it's paid once, and divided by thousands.

What the bet bought

Most of what native bought us lives below what users can name. The sensory layer: haptic feedback, parallax, motion, a tab bar that floats, scrolling with the system's exact physics, transitions that belong to the OS. A media player that keeps playing when the screen goes dark and follows the user from screen to screen. Local notifications that fire from the app binary itself when someone enters a geofence or walks near a beacon, with no server involved, which only exists when the app is real native code running with the operating system's own permissions. Each platform's own idioms, because three engines can be right in three worlds instead of average in two: the share sheet is Apple's on iOS and Android's on Android. And when Apple ships a new primitive at WWDC, we can adopt it as soon as it lands, with no framework in between that has to wrap it first.

It ended, but not the way we pictured

We expected the intermediate layers to wear out one by one, and we expected time to settle the bet. What settled it was AI, and from a direction we hadn't imagined. Instead of waiting for the hybrid frameworks to fade, it removed the only reason anyone had to use them. The whole case for a shared codebase was the cost of building twice, and models and agents now carry enough of the translation, the testing and the review across platforms that duplication stopped deciding anything. A team shipping one app can land today where we've been since 2011, on the platform's own languages with the platform's own tooling. Two roads to the same place, fifteen years apart: agents for them, architecture for us.
For us, AI lands on top of that structure rather than instead of it. Generated sections live inside apps whose engines were already native, and the model works with first-party toolchains, where it can test its own work fastest. We bet that the platforms would outlast everything built on top of them. They did. We just thought the proof would take longer, and come from somewhere else. The bet paid, not the way we pictured, which is usually how bets pay.

Mathieu Poli — Head of Frontend Engineering @ GoodBarber.
I teach and write about frontend engineering, product design, and AI — and everything that happens when the three meet.
X: @hellomathieup · LinkedIn: hellomathieup