Add startApp() for non-blocking app execution

[shikokuchuo]

Motivation

Shiny, being an httpuv server, inherently does not need to block — it uses the later event loop, which is designed for cooperative concurrency. Adding a non-blocking mode:

• Allows AI coding agents to programmatically start, test, and stop Shiny apps without blocking the R console and run multiple apps sequentially in the same session
• Opens up novel uses of Shiny as a UI for objects that live on in the user's interactive R session

Changes

Adds startApp(), a non-blocking counterpart to runApp():

# Start app in the background — returns immediately
handle <- startApp("myapp")

# Check status and URL
handle$status() # "running", "success" or "error"
handle$url()

# Stop when done
handle$stop()

# Access return value from stopApp()
handle$result() # throws if still running, re-throws errors

Implementation

• ShinyAppHandle (R6 class): Returned by startApp(). Provides methods for lifecycle management (stop(), status(), url()) and accessing the app's return value (result()).
• .setupShinyApp(): Shared initialization extracted from runApp(), used by both runApp() and startApp().
• serviceNonBlocking(): Runs the httpuv event loop via later callbacks instead of a blocking while loop.
• .createCleanup(): Consolidated cleanup logic shared between blocking and non-blocking modes.

Safeguards

• Only one app can run at a time (same as blocking mode)
• When a new app starts, any previously running non-blocking app is automatically stopped
• Finalizer ensures cleanup if handle is garbage collected
• Cleanup is idempotent (safe to call multiple times)

[shikokuchuo]

From a conversations with @hadley, we could tweak the UI further so that:

1. Starting a new app automatically stops the old one
2. Have it automatically run non-blocking if used by an agent (via env vars)

[hadley]

I like the model of automatically stopping the previously running app as it matches the existing model pretty closely; it just skips the step of having to Ctrl + C to quit the current app.

I would hope that eventually nonblocking mode becomes the default, but defaulting to only during LLM usage would be a good place to start.

[shikokuchuo]

Thanks @hadley, starting a new app now automatically stops the old one, and non-blocking is the default for LLMs.
Am reviewing with @cpsievert and @schloerke later this week.

[shikokuchuo]

@shikokuchuo Could you please update the PR description?

Ah, of course - all done now!

[cpsievert]

A few issues spotted during review — details in inline comments.

[cpsievert]

A few targeted follow-ups from local verification. The main correctness issue is the startup-time stop path in startApp(). I also think the fixed 1 ms polling loop is worth revisiting before this lands. Details are inline.

[cpsievert]

Great work, thanks @shikokuchuo!