What about the simulator contract? I think there could be some things to discuss here, like how to control having Expo Go preinstalled after the split

This behavior is exactly why I am pushing back on REST a bit

I've worked on a system I called "page2api", which was a wrapper for Playwright scripts to present as if a certain service had an API. It had "sessions", which were leased browsers underneath

I've published a TypeScript SDK to consumers and have changed the transport to notify on leasing states like 3 times (retries -> long polling -> WebSocket) over a year for various reasons (performance, stability, command batching)

Here I would have gradually push for the same - maybe even adopt gRPC at some point, abstracted away in an SDK package

Being constrained to REST limits the scope of solutions we could implement for future problems

Not that anybody wanted to, but I'd like to say this: If we add metadata JSON, let's not kill tags, those aren't superseded by metadata, as they have their own neat rendering and they are algorithmic-ally cheap to filter by

As much as I like having REST API specs (especially for E2E tests, monitoring, etc.), I'd like to push back slightly, as this would slow our agents down, and it does not cleanly fit all of our features (i.e. log streaming would be poorly defined with REST)

Worth noting, that lim.run, for instance, only exposes many of their features as CLI and SDK, but NOT API https://docs.limrun.com/docs/ios/build-with-xcode

I believe this is deliberate; the define contracts with CLI and SDK types so that the agent can quickly reassemble internal implementation as needed

If the push for OpenAPI is mainly to support trace id, can we also investigate how to integrate it in places that don't cleanly map to REST?

Nice! We get to remove dead code for once haha

Why not?

As in "what failure scenario will justify having to rotate two sets of credentials if we have to"

Can we clarify that this is only bad if it's a "change of an existing feature" and not an "addition"?

I really liked how during my agentic loops that covered Newly, run.cloud and the fleet all at once, I've had both a new feature for Newly appear and something useful for our customer base too

Case in point: iOS/Android log streaming, added for Newly's debugging, got commended for it by minitap.ai

One thing I'd like to mention in run.cloud's product statement, that first-class support for some React Native-related and AI-related features should be included

For example, the Metro bundler tunneling

One might say "Newly needs it, Newly can implement it in their user land", but a) shipping purpose-built features in run.cloud's fleet was sometimes cheaper than solving a general purpose mechanism b) our customer base is heavy on AI, and they sometimes offer first class support for React Native too (like minitap.ai)

Basically, I'd like to caution everybody against too hard of a split, so as not to lose benefits of dogfooding

So in relation to observability note, I'd rather not commit to any decision now here