How do you reproduce a bug reliably: environment, feature flags, seeded data, launch arguments, simulator tools and network conditions?

Start by writing down what could differ between your machine and the failure: the build (version, configuration, which commit), OS and device, the user’s account and data, settings (language, region, time zone, Dynamic Type, dark mode, accessibility), permissions granted or denied, network quality and the server environment, feature flags and remote config, and timing and ordering. Then make each of those controllable. Use launch arguments and environment variables (set in the scheme, or by a UI test, Q449) to switch on a debug mode, choose a stub server or force a flag; ship a hidden debug menu in internal builds to set flags, switch environments and load a seeded data set (a known account, a fixture database) instead of clicking through setup; and keep the production data’s shape in an anonymised fixture so you can replay the case.

The simulator is a control panel: xcrun simctl can push a notification payload, change privacy permissions (grant, revoke or reset), set a location, openurl for deep links and universal links, override the status_bar for screenshots, and erase a device to a clean state, as the check below lists. Combine that with the Network Link Conditioner or a proxy for slow, lossy or offline conditions, the scheme’s language and region options, a changed system time zone, and Low Power Mode. If it only fails on a device, attach the debugger wirelessly and use logging. Once you can reproduce it, shrink it: remove steps until you have the smallest scenario, then turn it into an automated test so it can never return (Q357). If you cannot reproduce it, add logging and breadcrumbs for the next occurrence rather than guessing at a fix.