Changing DEPLOYMENT_LOCATION doesn't work. For now I blame MacOS container manager. I can modify some string in the build, run the app and observe that during execution I still see the old string. Then I navigate to XCInstall within DerivedData or within /private/tmp/MyApp.dst/Applications/ (if DEPLOYMENT_LOCATION to YES) and confirm that the string within the build is correct (new). Then I can run the build directly from the Finder from XCInstall and the behavior is still old. But if I copy the build to a different directory and run from there, the behavior is new! I.e. I see the new string. If I do "Clean build folder..." (Cmd-Shift-K) the app runs with the recent changes, but build time is much greater, as XCode does the full build. Very annoying... Debugging on real iPhone is much slower in my case, but it seems I'm forced to do it that way :(

Have you fixed that? Not only the build is generated on every run, the debug session picks up the old build. Looks like container manager caches the old build for some reason. If I run the latest build from .XCInstall I still see the previous build (i.e. latest changes and not visible in the executed app). If I copy that build to a different directory and run again, I see the new build executed. This drives me nuts.

You can reproduce the same thing by setting AdHoc certificate for the dev build instead of automatic signing. XCode launches the build and it runs well (with Fairplay media playing) but expectedly the debugging is not possible anymore.

@gebn Have you figure out some solution or workaround for the glitch issue, when the player transitions from an encrypted to an unencrypted segment? It is still present. Am I right that the bug reported to Apple is not public?