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]

What about running an app by printing a shinyApp() object?

I thought of this as well. It's convenient to be able to modify the behaviour of the implicit runApp() from the print method.

Also in this case, people call it primarily for the side effect of running the App. What runApp() returns then becomes secondary for me and I'm not so bothered about stability of return types.

[shikokuchuo]

@cpsievert just to update that I tested the Rstudio Run App button with options(shiny.blocking = FALSE), and the different options run in the same way as when blocking - nothing surprising in that regard.

[shikokuchuo]

Let's move this forward on the following basis (as discussed in today's team meeting):

• Add blocking = getOption("shiny.blocking", TRUE) to runApp()
• Make this NON-default for LLMs or otherwise

This has the following advantages:

• Strictly opt-in - no surprising behaviour
• We can still teach an LLM how to use non-blocking mode correctly via docs or a skill
• All current infra (incl. RStudio button) works in BOTH modes
• Single change location (no need to modify shinyApp print method etc.)

Noting that @schloerke continues to prefer 2 separate functions.

@cpsievert for you to approve this PR. Thanks!

[shikokuchuo]

Following discussion at Asilomar, non-blocking behaviour is now separated out into a startApp() function so it doesn't interfere at all with existing runApp() behaviour.

[cpsievert]

@shikokuchuo Could you please update the PR description?

[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.