App builds come back sooner, with fewer browser passes

When a specialist builds or changes an app, it can open the app in its own browser, use it the way you would, and look at each page at desktop width and at phone width as the mobile app shows it. Until now it did all of that on every build: it tried each new form or button in the browser after every publish, then photographed every page and fixed what it saw, often over two or three rounds, before it replied. That made a finished app slow to come back. It now treats the browser as a tool it reaches for when it helps, so you get your app back sooner.

How it works

• Quick checks after every publish. It still confirms the app built and loads without errors each time it publishes a change.
• The browser when it answers a question. It tries a control in the browser when running the code behind it can't show that it works, such as a form with several steps, or to reproduce a problem you reported.
• One look, one round of fixes. For a new app or a large visual change, it looks at the main pages at both widths, fixes what is broken or clearly off, and names any further polish in its reply instead of looping on it.
• Clear about what it tried. Its closing line still lists what it tested on real data and what it has not tested yet.