This month was about the moments right after your app works — sharing it, publishing it, and changing your mind about it. Three things got noticeably better.
Share your app and it actually looks like something
Until now, pasting your published app into WhatsApp, LinkedIn or a group chat gave people a bare web address. No name, no picture, nothing to click with confidence.
Now every app you publish carries its own name and description, so a shared link arrives as a proper card. Search engines can read it too, which means your app can be found rather than just visited by people you sent it to.
Two smaller things came with it. Your app's browser tab now shows the app's name instead of a long internal code. And when you hit share, the page is made viewable before the link leaves your screen — so nobody you send it to lands on “this project is private” any more.
Pick how it looks before it gets built
You have always been offered three design directions at the start of a build. The trouble was that they were described in words, with a small preview made of grey bars, so all three looked much the same.
Now each one shows you a real miniature of that design: its actual typeface, its corners, its spacing, and real content in it — a shop with products and prices, a dashboard with a figure and a chart, an editorial page with a headline. You can see the difference at a glance and pick the one you want, instead of guessing from a label.
When an edit does not land, we say so
This is the change we are happiest about, because it was quietly costing people their confidence.
Sometimes you ask for a change and nothing actually changes. Your app was fine before and it is fine after — the request just did not take. But the builder used to report that as “Needs repair”, which sounds like your app broke. It had not.
Now it tells you what really happened: the edit produced no change, your saved app is untouched, and here is what to try next. Nothing was broken, and we no longer imply it was.
In the same spirit, the builder stopped describing working apps like inspection failures. A build that runs and has a few cosmetic notes now says so calmly, and offers to publish or to fix the notes — your call, not a blocked door.
Builds that are waiting are no longer mistaken for builds that are stuck
If you build a lot in one day, we pace your builds so everyone gets a fair turn, and we tell you when yours will start. Your browser used to give up on the wait before the scheduled time arrived and show you a timeout, even though the build was queued and fine.
That is fixed. A queued build stays connected until it runs. A genuinely stalled one is still reported, as it should be.
Repairs get more than one attempt
When a build comes back with something visibly wrong — text you cannot read, a screen that looks empty — the builder tries to fix it before handing it to you. It used to get exactly one attempt, which was rarely enough.
It now gets up to three, learning from what the re-check found each time, inside the same time budget. It still will not touch more of your app than it could before, and it never saves a repair it could not verify.
A note on what we do not claim
Two of the changes above only became visible to us after we published a real app and read what actually got served, rather than trusting that the code was right. We would rather tell you what we measured than what we intended, so: the share picture on a published app is still PromptUI's, not your app's, and apps published before this month will not carry the new details until you publish them again. Both are on the list.
As always, if something is not right, tell the builder what to change in plain words. That is what it is for.