iOS: How to debug "freshly launching" an app from a URL

Question

When launching an app from a URL, there is a distinction between whether the URL is freshly launching an app, or if it's resuming an app that has been put into a suspended state.

My question is, how do I debug the process of a "fresh launch" from a URL? Hitting "Run" in Xcode automatically opens the app. Then, I have to suspend the app to reach Safari and access my test site. But if I close my suspended app, Xcode is no longer attached to it and I'm unable to debug.

Townshend

Answer 1

These steps can be followed on the device. Founded at this link.

1. Run the app from Xcode to install it on your device and then stop it from Xcode.
2. Force quit the app from the app switcher UI on the device.
3. Navigate to the scheme for the project in Xcode. Under the Run section's Info tab, there is a radio button for "Wait for executable to be launched". Make sure this is checked instead of the "Automatically" option.
4. Run the app from Xcode. It will not open on the device, but the debugger will wait for it to open and then it will attach to it.

On the simulator as suggested by Marc-Alexandre Bérubé.

1. Run your app on the simulator.
2. Force quit the app on the simulator. Press cmd+shift+(hit h twice). Swipe the app up.
3. Open your terminal and enter this xcrun simctl openurl booted http://yourdomain/path.

Grosbeak

For easier testing using the iOS Simulator, we can then use the Terminal and paste the command xcrun simctl openurl booted http://yourdomain/path to launch the app with the URL we want. – Horsefaced

But Xcode won't attach immediately when I start the app like that - what to do when I want it to stop in a breakpoint in the url parsing/routing code? – Clemence

@Clemence If you follow the steps correctly it should hit you breakpoint in the url parsing. – Grosbeak

The "wait for app to be launched" setting works in the Simulator. – Vogt

xcrun simctl openurl booted http://yourdomain/path doesn't work on real device for me :( – Voracious

Really important note. If you make any code changes, you have to turn OFF "Wait for executable" and build and run then stop. THEN turn back ON "Wait for...". Otherwise Xcode will not install the updated binary on your test device (at least in Xcode 10.1) – Glassblowing

If I do it this way, Xcode waits. But it won't show any debugging logs on its console. – Kiyokokiyoshi

@Kiyokokiyoshi you will only start seeing debugging in console when you open the app. – Grosbeak

Note that there won't be any debugging output (printf etc.) in the console this way, so its usefulness is severely limited. – Amphiboly

Answer 2

You need to configure your Xcode app scheme to wait for the app to be launched manually. Here is how you do it: http://blogmobile.itude.com/2013/09/03/how-to-debug-deep-linking-in-ios/.

You then need to copy the launch URL and paste it to Mobile Safari. This will launch your app, and make Xcode get attached to the running app process.

Gametophore

If you're debugging on the simulator, here's a tip: Yu can also edit the URL of a saved web clip. They're just plists in ~/Library/Application Support/iPhone Simulator/7.1-64/Library/WebClips. (Adjust that 7.1-64 as needed.) – Biaxial

Tip: I found my WebClips in ~/Library/Developer/CoreSimulator/Devices/{GUID}/data/Library/WebClips.(Xcode 7.1.1/Simulator 9.1) – Know

Remeber, links die... Care to update your answer with the contents of the link? – Whipstall

Internet Archive link since original link is gone: web.archive.org/web/20160311071930/http://blogmobile.itude.com/… – Haustellum

Should this still work? Pasting the url to Safari will just open the website over here. Sending it as a message to the fake Messages contacts Kate Bell / John Appleseed and then clicking the link works though. But the breakpoint in UIAppDelegate does not get hit :-/ – Clemence

Answer 3

While the answers that mention activating "Wait for executable to be launched" are good in theory, for various reasons these didn't work for me. On the simulator, though Xcode claimed it had "attached", no logs or breakpoints were ever shown. On-device I was running iOS 13, building from Xcode 10, and using Xcode 11 to load, so I didn't have any debugging symbols. That was more of a personal problem, I suspect on device debugging may have worked.

What worked best for me was just opening up Console.app on my mac, and using the OSLog APIs to get a solid stream of caveman debugging from the simulator.

1. Run the app from Xcode on the simulator.
2. Then immediately quit it on the simulator via the app launched (Cmd-Shift-H * 2)
3. Launch the app by tapping a deep link I sent to myself via the Messages app
4. Observe my logs in Console.app

It's not pretty, but it is highly reliable.

It's also worth mentioning, that you can protect this useful feature by testing cold start deep-linking via XCUITest. You can call app.terminate in your XCUITests, then open a deep link (typically via a static web page you've setup, I use public GitHub wikis for this) and write tests and assert behaviors just like normal.

Cheffetz

"caveman debugging" works in a lot of situations, good advice and a good habit to be in – Equipage

thank you I have spend 2 days trying to figure out how to do this, at first was difficult but this guide shows all: avanderlee.com/workflow/oslog-unified-logging – Incoercible