Skip to main content
Test your Mini App in the real host environment before you submit, not just in your own dev server. Most issues, from a broken wallet handshake to an iOS crash, only show up once your app is running inside the Startale App.

​
Preview

The fastest way to test: no local setup, no deploy required.
Open app.startale.com/developers/preview and load any URL. It renders your Mini App inside the Startale App frame and exercises the wallet handshake, so you can test a live or local (via tunnel) build immediately. Use this as your default for day-to-day testing.

​
Sandbox

For a secondary way to test, the miniapp-sandbox repo runs a local approximation of the Startale App host on your machine. It still needs an internet connection, for example to reach the host wallet connector, same as production.
Preview remains the main platform to test your Mini App and see a real environment, and stays more up to date. The sandbox is open to any Mini App developer as an alternative.
Sandbox runs at localhost:3100. Register your Mini App by editing src/pages/configMiniApps.ts:
It auto-fetches your Mini App’s /.well-known/farcaster.json to populate the launcher card.
Known gaps:
  • eoaWallets is not simulated. Test EOA-discovery flows against staging or production.
  • Notifications via addMiniApp work locally only if you have configured a webhook endpoint reachable from the sandbox.
  • sendToken and swapToken actions return not_supported in the sandbox.
Iframe sandbox attributes:
Your Mini App must function with these attributes. For example, popups opened from inside the iframe escape the sandbox, which is required for the Startale wallet popup.

​
iOS Safari

The Startale App renders on iOS using a WKWebView, the same engine behind Safari. iOS enforces a much tighter memory ceiling on web content than desktop browsers, and it terminates the page without warning once a Mini App exceeds it. If your Mini App has not been tested there, you do not know whether it survives.
iOS gives no warning before it terminates a page over its memory budget. There is no dialog, no error message, and no crash log visible to you, the Mini App just disappears. Passing iOS Safari is the strongest signal that your Mini App is stable everywhere else too.
What to test, on a physical iOS device, not just at launch:
  • Cold start. Open the Mini App from a fresh state and confirm it reaches sdk.actions.ready() without crashing.
  • Extended play. For game or interactive Mini Apps, keep a session running for several minutes. Several reported crashes happen after a few minutes of gameplay, not immediately on load.
  • Background and resume. Send the Startale App to the background mid-session, then bring it back to the foreground.
  • Navigation. Move between screens inside your Mini App repeatedly. Memory that is not released between screens accumulates over a session.
  • Older devices. Test on an older or lower-memory iPhone in addition to a current model. Memory ceilings are tighter there, and issues surface sooner.
1

Use a physical device

The iOS Simulator does not reproduce Safari’s memory constraints. Test on an actual iPhone.
2

Enable Web Inspector on the device

On the iPhone: Settings > Safari > Advanced > Web Inspector.
3

Connect from a Mac

Connect the iPhone to a Mac, open Safari, then Develop > [Your iPhone] > [Your Mini App]. This opens Web Inspector for the page running inside the Startale App’s WKWebView.
4

Watch memory while you play

Use the Web Inspector’s Timelines tab to watch memory during the test scenarios above. A memory graph that climbs continuously and never comes back down is the signature of a leak, and is what precedes a crash.
Common causes of memory crashes, if a test above fails:
  • Large or uncompressed image, audio, and video assets loaded into memory at once instead of streamed or released after use.
  • Canvas or WebGL contexts left open, or textures not disposed when a screen unmounts.
  • Event listeners, intervals, or animation frame callbacks that are never cleaned up between screens.
  • Game or app state that keeps growing in memory over a session instead of being capped or paginated.
  • Detached DOM nodes or objects kept alive by lingering references, such as closures, global arrays, or caches, after a screen unmounts.

​
Other platforms

Android and desktop browsers are less memory-constrained than iOS Safari, but verify your Mini App on a physical Android device and on desktop before submitting. The same cold start, extended play, and background/resume checks apply.

​
Before you submit

Test on iOS Safari, at minimum, before every submission and every significant update. See Submission for the full requirements list.