How to remove the RoomPlan Debug Metal HUD in iOS 16? - ios

The problem:
The console is filled with debug data making it impossible to log anything else.
The iPad screen shows a lot of metal HUD views making creating screenshots impossible.
What I have tried:
Setting the:
Scheme -> Diagnostics -> Metal: API Validation flag to false or (true)
Checking the docu for several RoomPlan classes and structs for words like:
debug, show, logging, log...
RoomCaptureSession.Configuration, RoomCaptureView
Running the app in the Release build configuration (since the Debug was set per default).
Several google searches
Use a different demo project to verify if the issue is project-specific.
Official Apple Demo Project
Screenshots:

Disable Metal Debug Data in Console
Go to Xcode 14.2 main menu:
Product – Scheme – Edit Scheme – Run (Debug) – Arguments and add environment variable.
// Name Value
OS_ACTIVITY_MODE = disable
Disable Metal Performance HUD
Product – Scheme – Edit Scheme – Run (Debug) – Diagnostics and disable two options:
Or, when Developer Mode is enabled, disable it in iPadOS under
Settings app – Developer (scroll down):

Related

Is there a way to disable firebase analytics with a scheme argument in Xcode?

I want to disable firebase analytics from collecting & sending events when I'm building, testing & debugging via an Xcode scheme argument, if able.
I'm aware you can edit the info.plist to disable (Firebase Docs) but would prefer a solution that doesn't require me to edit the .plist every time I'd like to switch between enabled and disabled.
Any suggestions?
You can configure two different plists into two different build targets, each with an associated scheme.
Details here.
Solution I came up with is very similar to Paul Beusterien's answer, but doesn't require a seperate scheme.
I made a copy of my current info.plist and named it info-debug.plist. I added the required key and value to disable firebase analytics.
FIREBASE_ANALYTICS_COLLECTION_ENABLED = 0
Then I selected my scheme Testing and under Packing -> Info.plist File -> Debug I set the value to info-debug.plist
Anytime I build and run my app in Xcode it will use info-debug.plist because my Build Configuration is set to the default: Debug. When I archive my app it will use info.plist as set by the Build Configuration for Release.
https://medium.com/geekculture/what-are-debug-and-release-modes-in-xcode-how-to-check-app-is-running-in-debug-mode-8dadad6a3428
Debug vs Release Mode
When you create a new project in Xcode, it defines two build
configurations, Debug and Release. By default, Debug configuration is
used during development whereas the Release configuration is used for
TestFlights or App Store. In other words, when you run the app on the
simulators or real devices by hitting the Run button(cmd + R), your
app is running with Debug configuration, aka Debug mode; when you
archive and upload a build to App Store Connect, app is running in
Release mode. However, this is just the default behavior. Technically,
you can run apps on simulators in any mode you want. It’s also true
for archiving(builds that you upload to the App Store Connect). To
change build configurations for development and archiving, you can go
to Product → Scheme → Edit Scheme(Command + <):

How to debug in Xcode

I am trying to debug an iOS app in Xcode. My scheme is with the Build Configuration in Debug. When I run the application, the Debug panel opens but when the application opens in the simulator or on the device, the panel closes and does not allow me to debug.
What are the conditions that must be met in order to debug an application in Xcode?
My Xcode version is 11.3.1.
My macOS version is 10.15.2.
Update 1
I put image of my configurations:
When I try to attach the debug to simulator by "Attach to Process by PID or Name..." I have the following error:
The scheme you are running must be enabled for Debugging. This is the default but it might have been changed, by accident, or during experimentation.
Here is a correct example, enabling debug.
Ensure you have set some breakpoints.
Furthermore, it might be that your preference settings are incorrect for debugging.
The following settings need to be checked in Xcode > Preferences; Behaviour Tab.
Note two checked items for the Running Pauses left panel selection:
Note that when Xcode is installed, upon first use it will prompt for Developer Access to your system requiring a password for the Administrator privileged account (normally your own account has such privilege).
In order for debug attach to work, Developer Mode must be enabled. This can be checked:
# DevToolsSecurity -verbose -status
Getting rights definition for: system.privilege.taskport.debug
Current rights definition dictionary:
"k-of-n" : 1
"class" : "rule"
"created" : 582290628
"version" : 0
"modified" : 589046609
"comment" : "For use by Apple. WARNING: administrators are advised
not to modify this right."
"rule" : { "is-admin", "is-developer", "authenticate-developer" }
Developer mode is currently enabled.
To enable developer mode if it is not enabled, use
# sudo DevToolsSecurity -enable
Put breakpoints to your code whatever you want to debug by clicking the number of line.
Hope it helps...

iOS custom keyboard settings not saving

I’m implementing a settings bundle for a custom keyboard using the Apple Keyboard Extension documentation and the settings tutorial it links to.
This method works in the parent app, but when I implement it as identically as possible for the keyboard extension, the settings bundle does not appear to save any of the data, as shown in this video. It seems as if something is resetting the values near-constantly: any time I exit the settings view (e.g. Multitasking view, previous settings page), the values are set to zero (not default: empty, false, and zero respectively). This is the default settings bundle template, no edits, not referred to in code.
Is there a special implementation for extension settings not explicitly stated in the documentation (or that I missed) that is causing this?
For clarity, the steps I took (after creating the extension):
Created the bundle with New File –> Settings Bundle.
Named it, targeted the keyboard extension.
Built and ran.
These were the same steps I took for the parent app (targeting the app), which was able to save settings.
This is on a physical iOS 11.0 (15A5326a) device; app built with Xcode 9.0 (9M202q), Swift 4.

How to set Stripping Level for iOS in Unity

Where can I find the option to set the Stripping Level for iOS? I couldn't find it in Build Settings -> Player Settings. I am using Unity 5.3.4.
iOS in Unity now uses IL2CPP instead of mono.
IL2CPP automatically strips unused stuff, so you can't customise it in the build settings anymore beyond the 'Strip Engine Code' tick box.
See the 'Stripping with IL2CPP' section of this document for more detailed information: iOS Optimisation

Breakpoints still fire in Release mode of the XCode 5.5.1 build schema for IOS

I am used to creating a Release schema for OSX applications, whereby I switch build mode to Release, and set the debugger to None. This removes the breakpoint info from the app and optimises it.
Although I can set the Release mode for the IOS applications, there is no way to set the debugger to None. And, it occurs that in the Release mode the breakpoints are still honored by XCode 5.5.1, which tells me that the debug info is still compiled into the app.
How can I make sure that my IOS app is as pristine as possible, and does not have debug info, and does not fire the breakpoints in Xcode, while running on the device?
Thanks.
EDIT: Solution is to set "Generate Debug Symbols" to No in Release build.
Having breakpoints enabled (or not) doesn't change the size of your code. Your Release scheme should be setting "Optimization Level" -Os, "Symbols Hidden by Default" to Yes and "Strip Debug Symbols During Copy" to Yes. All of these are default options in new projects, so you really shouldn't have to change anything.
Even in a release build, breakpoints will still function because the symbolic information is stored separately from the built product.
I think your confused on breakpoints vs debugging symbols. Your release build by default should remove debugging symbols from the final product. However that doesn't stop you from attaching a debugger to it. You can hook a debugger up to any app you want (mostly true), however if the debugging symbols are striped then all you'll be able to see is the assembly instructions. This is what you see when you try to step into Apples frameworks from your own code.

Resources