We got the newly issue that our Test devices keeps us asking for the pin code to "Enable UI Automation". Then it works for some hours or days, but after some time it starts again. "Enable UI Automation" is already enabled in "Settings" - "Developer" menu. The devices are located remotely and we can't access them directly, so this is a big issue for us right now. Is there any way to avoid this?

So apparently Monterey has switched to creating .ips files instead of .crash files for application crashes. Console.app can convert these .ips files to "old-style" crash format. But is there a command-line tool to do the same thing?

I made a minor change the UI of my tvOS App, and am now getting errors related to the App Icon. I have confirmed that all the background images DO match the requirements but App Store Connect won't let me upload: App Store Connect Operation Error Invalid Image Asset. The image stack 'App Icon' in 'Payload/My TV.app/Assets.car' has a background layer image that does not match the canvas dimensions '400x240'. App Store Connect Operation Error Invalid Image Asset. The image stack 'App Icon' in 'Payload/My TV.app/Assets.car' has a background layer image that does not match the canvas dimensions '800x480'. App Store Connect Operation Error Invalid Image Asset. The image stack 'App Icon' in 'Payload/My TV.app/Assets.car' has a background layer image that does not match the canvas dimensions '1280x768'. App Store Connect Operation Error Invalid Image Asset. The image stack 'App Icon' in 'Payload/My TV.app/Assets.car' has a background layer image that does not match the canvas dimensions '2560x1536'. App Store Connect Operation Error Invalid Image Asset. The App Store Icon must only contain an image with size (1280pt × 768pt @1x). Refer to https://developer.apple.com/tvos/human-interface-guidelines/icons-and-images/app-icon for more information Have the standards changed? Or is there another issue I should be looking at? Thanks!

Hello everyone, I'm having a little issue with mounting my external hard drive lately. I've tried quite a few methods in hope of getting it to work again, but so far, no luck. I hope someone can help me solve this issue, or those who have the same problem may also share your insights. My external hard drive was working fine about a week ago. But one day, I ejected the hard drive and the icon disappeared, so I thought it was safe to unplug it. When I did, it said the hard drive was not properly removed. It still works fine when I use it the next day, but the same thing happened. It said the drive was not properly removed after I ejected the drive, waited for the icon to disappear, and then unplugged the drive. After that, it never works again, and the attached images are the info I got when I tried to mount or run first aid on this drive. Please help & thank you in advance! Computer: 27" iMac - MacOS Monterey External Hard Drive: WD_Black 4TB. APFS encrypted

Are you able to reproduce the issue? Yes What software version(s) and hardware have you reproduced the issue on? iOS 14, iOS 15 iPhone XR, iPhone 12 simulator (On All iOS devices) Description When trying to import a P12 certificate using the API SecPKCS12Import, it is failing with error errSecDecode = -26275 since 09/23 in production. We tried to figure out the change in our code base (client as well as server side) that might have triggered this failure but there is no change on either side. The same P12 certificate is successfully validated using the below mentioned openssl command on the terminal. openssl pkcs12 -in -passin pass: Please can you tell us how we may debug the API SecPKCS12Import and understand what might be incorrect in P12 certificate format due to which it has started failing. Note: The same code (with zero change) was working fine in production until 09/23. If required, we may share the p12 certificate and associate password with you to debug it further.

XCode version 13.2.1 I enabled os_log messages using the following code:    let myLog = OSLog(subsystem: "testing", category: "exploring")   override func viewDidLoad() {     os_log("LOGGING TEST BLAH BLAH", log: myLog)     print("Starting ViewDidLoad")     super.viewDidLoad()     os_log("LOGGING TEST BLAH BLAH", log: myLog)' ... However, I do not see anything on the XCode console - just the print ("Starting ViewDidLoad"). Is there a setting in XCode to echo messages from the logger that needs to be turned on? I understand that Logger is the preferred method now instead of os_log, but both should echo the log messages on XCode debug console from what I can tell.. Thanks!

I'm trying to use task_for_pid in a project but I keep getting error code 5 signaling some kind of signing error. Even with this script I cant seem to get it to work. #include <mach/mach_types.h> #include <stdlib.h> #include <mach/mach.h> #include <mach/mach_error.h> #include <mach/mach_traps.h> #include <stdio.h> int main(int argc, const char * argv[]) {   task_t task;   pid_t pid = argc >= 2 ? atoi(argv[1]) : 1;   kern_return_t error = task_for_pid(mach_task_self(), pid, &task);   printf("%d -> %x [%d - %s]\n", pid, task, error, mach_error_string(error));   return error; } I've tried signing my executables using codesign and also tried building with Xcode with the "Debugging Tool" box checked under hardened runtime. My Info.plist file includes the SecTaskAccess key with the values "allowed" and "debug." Hoping someone can point me towards what I'm missing here. Thanks!

[Q] What is the thread safety status of the IOBluetooth framework? Is it possible call any class from the IOBluetooth framework from a secondary thread? I haven't found so far information about this in the documentation and the only pieces of info you can find through a google search say the framework is not thread safe but these are old pieces of info.

The unified system log on Apple platforms gets a lot of stick for being ‘too verbose’. I understand that perspective: If you’re used to a traditional Unix-y system log, you might expect to learn something about an issue by manually looking through the log, and the unified system log is way too chatty for that. However, that’s a small price to pay for all its other benefits. This post is my attempt to explain those benefits, broken up into a series of short bullets. Hopefully, by the end, you’ll understand why I’m best friends with the system log, and why you should be too! If you have questions or comments about this, start a new thread and tag it with OSLog so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Your Friend the System Log Apple’s unified system log is very powerful. If you’re writing code for any Apple platform, and especially if you’re working on low-level code, it pays to become friends with the system log! The Benefits of Having a Such Good Friend The public API for logging is fast and full-featured. And it’s particularly nice in Swift. Logging is fast enough to leave log points [1] enabled in your release build, which makes it easier to debug issues that only show up in the field. The system log is used extensively by the OS itself, allowing you to correlate your log entries with the internal state of the system. Log entries persist for a long time, allowing you to investigate an issue that originated well before you noticed it. Log entries are classified by subsystem, category, and type. Each type has a default disposition, which determines whether that log entry is enable and, if it is, whether it persists in the log store. You can customise this, based on the subsystem, category, and type, in four different ways: Install a configuration profile created by Apple (all platforms). Add an OSLogPreferences property to your app’s Info.plist (all platforms). Run the log tool with the config command (macOS only) Create and install a custom configuration profile with the com.apple.system.logging payload (macOS only). When you log a value, you may tag it as private. These values are omitted from the log by default but you can configure the system to include them. For information on how to do that, see Recording Private Data in the System Log. The Console app displays the system log. On the left, select either your local Mac or an attached iOS device. Console can open and work with log snapshots (.logarchive). It also supports surprisingly sophisticated searching. For instructions on how to set up your search, choose Help > Console Help. Console’s search field supports copy and paste. For example, to set up a search for the subsystem com.foo.bar, paste subsystem:com.foo.bar into the field. Console supports saved searches. Again, Console Help has the details. Console supports viewing log entries in a specific timeframe. By default it shows the last 5 minutes. To change this, select an item in the Showing popup menu in the pane divider. If you have a specific time range of interest, select Custom, enter that range, and click Apply. Instruments has os_log and os_signpost instruments that record log entries in your trace. Use this to correlate the output of other instruments with log points in your code. Instruments can also import a log snapshot. Drop a .logarchive file on to Instruments and it’ll import the log into a trace document, then analyse the log with Instruments’ many cool features. The log command-line tool lets you do all of this and more from Terminal. The log stream subcommand supports multiple output formats. The default format includes column headers that describe the standard fields. The last column holds the log message prefixed by various fields. For example: cloudd: (Network) [com.apple.network:connection] nw_flow_disconnected … In this context: cloudd is the source process. (Network) is the source library. If this isn’t present, the log came from the main executable. [com.apple.network:connection] is the subsystem and category. Not all log entries have these. nw_flow_disconnected … is the actual message. There’s a public API to read back existing log entries, albeit one with significant limitations on iOS (more on that below). Every sysdiagnose log includes a snapshot of the system log, which is ideal for debugging hard-to-reproduce problems. For more details on that, see Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem. For general information about sysdiagnose logs, see Bug Reporting > Profiles and Logs. But you don’t have to use sysdiagnose logs. To create a quick snapshot of the system log, run the log tool with the collect subcommand. If you’re investigating recent events, use the --last argument to limit its scope. For example, the following creates a snapshot of log entries from the last 5 minutes: % sudo log collect --last 5m For more information, see: os > Logging OSLog log man page os_log man page (in section 3) os_log man page (in section 5) WWDC 2016 Session 721 Unified Logging and Activity Tracing [1] Well, most log points. If you’re logging thousands of entries per second, the very small overhead for these disabled log points add up. Foster Your Friendship Good friendships take some work on your part, and your friendship with the system log is no exception. Follow these suggestions for getting the most out of the system log. The system log has many friends, and it tries to love them the all equally. Don’t abuse that by logging too much. One key benefit of the system log is that log entries persist for a long time, allowing you to debug issues with their roots in the distant past. But there’s a trade off here: The more you log, the shorter the log window, and the harder it is to debug such problems. Put some thought into your subsystem and category choices. One trick here is to use the same category across multiple subsystems, allowing you to track issues as they cross between subsystems in your product. Or use one subsystem with multiple categories, so you can search on the subsystem to see all your logging and then focus on specific categories when you need to. Don’t use too many unique subsystem and context pairs. As a rough guide: One is fine, ten is OK, 100 is too much. Choose your log types wisely. The documentation for each OSLogType value describes the default behaviour of that value; use that information to guide your choices. Remember that disabled log points have a very low cost. It’s fine to leave chatty logging in your product if it’s disabled by default. No Friend Is Perfect The system log API is hard to wrap. The system log is so efficient because it’s deeply integrated with the compiler. If you wrap the system log API, you undermine that efficiency. For example, a wrapper like this is very inefficient: -*-*-*-*-*- DO NOT DO THIS -*-*-*-*-*- void myLog(const char * format, ...) { va_list ap; va_start(ap, format); char * str = NULL; vasprintf(&str, format, ap); os_log_debug(sLog, "%s", str); free(str); va_end(ap); } -*-*-*-*-*- DO NOT DO THIS -*-*-*-*-*- This is mostly an issue with the C API, because the modern Swift API is nice enough that you rarely need to wrap it. If you do wrap the C API, use a macro and have that pass the arguments through to the underlying os_log_xyz macro. iOS has very limited facilities for reading the system log. Currently, an iOS app can only read entries created by that specific process, using .currentProcessIdentifier scope. This is annoying if, say, the app crashed and you want to know what it was doing before the crash. What you need is a way to get all log entries written by your app (r. 57880434). There are two known bugs with the .currentProcessIdentifier scope. The first is that the .reverse option doesn’t work (r. 87622922). You always get log entries in forward order. The second is that the getEntries(with:at:matching:) method doesn’t honour its position argument (r. 87416514). You always get all available log entries. Xcode 15 beta has a shiny new console interface. For the details, watch WWDC 2023 Session 10226 Debug with structured logging. For some other notes about this change, search the Xcode 15 Beta Release Notes for 109380695. In older versions of Xcode the console pane was not a system log client (r. 32863680). Rather, it just collected and displayed stdout and stderr from your process. This approach had a number of consequences: The system log does not, by default, log to stderr. Xcode enabled this by setting an environment variable, OS_ACTIVITY_DT_MODE. The existence and behaviour of this environment variable is an implementation detail and not something that you should rely on. Xcode sets this environment variable when you run your program from Xcode (Product > Run). It can’t set it when you attach to a running process (Debug > Attach to Process). Xcode’s Console pane does not support the sophisticated filtering you’d expect in a system log client. When I can’t use Xcode 15, I work around the last two by ignoring the console pane and instead running Console and viewing my log entries there. If you don’t see the expected log entries in Console, make sure that you have Action > Include Info Messages and Action > Include Debug Messages enabled. The system log interface is available within the kernel but it has some serious limitations. Here’s the ones that I’m aware of: Prior to macOS 14.4, there was no subsystem or category support (r. 28948441). There is no support for annotations like {public} and {private}. Adding such annotations causes the log entry to be dropped (r. 40636781). Metal shaders can log using the interface described in section 6.19 of the Metal Shading Language Specification. Revision History 2024-10-22 Added some notes on interpreting the output from log stream. 2024-09-17 The kernel now includes subsystem and category support. 2024-09-16 Added a link to the the Metal logging interface. 2023-10-20 Added some Instruments tidbits. 2023-10-13 Described a second known bug with the .currentProcessIdentifier scope. Added a link to Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem. 2023-08-28 Described a known bug with the .reverse option in .currentProcessIdentifier scope. 2023-06-12 Added a call-out to the Xcode 15 Beta Release Notes. 2023-06-06 Updated to reference WWDC 2023 Session 10226. Added some notes about the kernel’s system log support. 2023-03-22 Made some minor editorial changes. 2023-03-13 Reworked the Xcode discussion to mention OS_ACTIVITY_DT_MODE. 2022-10-26 Called out the Showing popup in Console and the --last argument to log collect. 2022-10-06 Added a link WWDC 2016 Session 721 Unified Logging and Activity Tracing. 2022-08-19 Add a link to Recording Private Data in the System Log. 2022-08-11 Added a bunch of hints and tips. 2022-06-23 Added the Foster Your Friendship section. Made other editorial changes. 2022-05-12 First posted.

I've got an app that is sandboxed, and it requires a privileged helper. I've worked through the EBAS sample app with various updates to conform with current systems. After a lot of work, I've got to a point where I'm stumped. The Python script SMJobBlessUtil.py returns this error, and I don't know what to do to correct it: &lt;path to helper tool&gt;: tool __TEXT / __info_plist section dump malformed (2) I've gone over the various settings numerous times. It doesn't fail for the EBAS sample, but does for my app. Looking at the binary, the __info_plist sections look identical apart from identifiers. This is what mine looks like (identifiers deleted): &lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt; &lt;plist version="1.0"&gt; &lt;dict&gt; &lt;key&gt;CFBundleIdentifier&lt;/key&gt; &lt;string&gt;***&lt;/string&gt; &lt;key&gt;CFBundleInfoDictionaryVersion&lt;/key&gt; &lt;string&gt;6.0&lt;/string&gt; &lt;key&gt;CFBundleName&lt;/key&gt; &lt;string&gt;***&lt;/string&gt; &lt;key&gt;CFBundleVersion&lt;/key&gt; &lt;string&gt;1.0&lt;/string&gt; &lt;key&gt;SMAuthorizedClients&lt;/key&gt; &lt;array&gt; &lt;string&gt;anchor apple generic and identifier "***" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "***")&lt;/string&gt; &lt;/array&gt; &lt;/dict&gt; &lt;/plist&gt; I must be missing something, but I've run out of ideas on where to find it. Anybody got a pointer?

Logging in with my Apple ID anywhere in the system (feedback assistant, Xcode, iCloud, etc.) fails when running under virtualization. Is this a known 'issue'? (networking in general is working fine)

Mac users often ask whether they should install "anti-virus" software. The answer usually given on ASC is "no." The answer is right, but it may give the wrong impression that there is no threat from what are loosely called "viruses." There is a threat, and you need to educate yourself about it. This is a comment on what you should—and should not—do to protect yourself from malicious software ("malware") that circulates on the Internet and gets onto a computer as an unintended consequence of the user's actions. It does not apply to software, such as keystroke loggers, that may be installed deliberately by an intruder who has hands-on access to the computer, or who has been able to log in to it remotely. That threat is in a different category, and there's no easy way to defend against it. The comment is long because the issue is complex. The key points are in sections 5, 6, and 10. OS X now implements three layers of built-in protection specifically against malware, not counting runtime protections such as execute disable, sandboxing, system library randomization, and address space layout randomization that may also guard against other kinds of exploits. 2. All versions of OS X since 10.6.7 have been able to detect known Mac malware in downloaded files, and to block insecure web plugins. This feature is transparent to the user. Internally Apple calls it "XProtect." The malware recognition database used by XProtect is automatically updated; however, you shouldn't rely on it, because the attackers are always at least a day ahead of the defenders. The following caveats apply to XProtect: ☞ It can be bypassed by some third-party networking software, such as BitTorrent clients and Java applets. ☞ It only applies to software downloaded from the network. Software installed from a CD or other media is not checked. As new versions of OS X are released, it's not clear whether Apple will indefinitely continue to maintain the XProtect database of older versions such as 10.6. The security of obsolete system versions may eventually be degraded. Security updates to the code of obsolete systems will stop being released at some point, and that may leave them open to other kinds of attack besides malware. 3. Starting with OS X 10.7.5, there has been a second layer of built-in malware protection, designated "Gatekeeper" by Apple. By default, applications and Installer packages downloaded from the network will only run if they're digitally signed by a developer with a certificate issued by Apple. Software certified in this way hasn't necessarily been tested by Apple, but you can be reasonably sure that it hasn't been modified by anyone other than the developer. His identity is known to Apple, so he could be held legally responsible if he distributed malware. That may not mean much if the developer lives in a country with a weak legal system (see below.) Gatekeeper doesn't depend on a database of known malware. It has, however, the same limitations as XProtect, and in addition the following: ☞ It can easily be disabled or overridden by the user. ☞ A malware attacker could get control of a code-signing certificate under false pretenses, or could simply ignore the consequences of distributing codesigned malware. ☞ An App Store developer could find a way to bypass Apple's oversight, or the oversight could fail due to human error. Apple has so far failed to revoke the codesigning certificates of some known abusers, thereby diluting the value of Gatekeeper and the Developer ID program. These failures don't involve App Store products, however. For the reasons given, App Store products, and—to a lesser extent—other applications recognized by Gatekeeper as signed, are safer than others, but they can't be considered absolutely safe. "Sandboxed" applications may prompt for access to private data, such as your contacts, or for access to the network. Think before granting that access. Sandbox security is based on user input. Never click through any request for authorization without thinking. 4. Starting with OS X 10.8.3, a third layer of protection has been added: a "Malware Removal Tool" (MRT). MRT runs automatically in the background when you update the OS. It checks for, and removes, malware that may have evaded the other protections via a Java exploit (see below.) MRT also runs when you install or update the Apple-supplied Java runtime (but not the Oracle runtime.) Like XProtect, MRT is effective against known threats, but not against unknown ones. It notifies you if it finds malware, but otherwise there's no user interface to MRT. 5. The built-in security features of OS X reduce the risk of malware attack, but they are not, and never will be, complete protection. Malware is a problem of human behavior, and a technological fix is not going to solve it. Trusting software to protect you will only make you more vulnerable. The best defense is always going to be your own intelligence. With the possible exception of Java exploits, all known malware circulating on the Internet that affects a fully-updated installation of OS X 10.6 or later takes the form of so-called "****** horses," which can only have an effect if the victim is duped into running them. The threat therefore amounts to a battle of wits between you and the scam artists. If you're smarter than they think you are, you'll win. That means, in practice, that you always stay within a safe harbor of computing practices. Malware defence By Linc Davis - https://discussions.apple.com/thread/6460085

Here is my ci_post_clone.sh #!/bin/sh # fail if any command fails set -e # debug log set -x # Install CocoaPods using Homebrew. HOMEBREW_NO_AUTO_UPDATE=1 # disable homebrew's automatic updates. brew install cocoapods # Install Flutter using git. git clone https://github.com/flutter/flutter.git -b stable $HOME/flutter export PATH="$PATH:$HOME/flutter/bin" # Install Flutter artifacts for iOS (--ios), or macOS (--macos) platforms. flutter precache --ios # Install Flutter dependencies. flutter channel master flutter doctor flutter pub get # Generate IOS file flutter build ios --release --no-codesign # Install CocoaPods dependencies. #cd ios && pod install # run `pod install` in the `ios` directory. exit 0

General: DevForums tags: Files and Storage, Finder Sync, File Provider, Disk Arbitration, APFS File System Programming Guide On File System Permissions DevForums post File Provider framework Finder Sync framework App Extension Programming Guide > App Extension Types > Finder Sync Disk Arbitration Programming Guide Mass Storage Device Driver Programming Guide Device File Access Guide for Storage Devices Apple File System Guide TN1150 HFS Plus Volume Format Extended Attributes and Zip Archives File system changes introduced in iOS 17 DevForums post Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Right, this is getting on my nerves now. iOS app installed on iPhone via Xcode. Watch app installed on Watch via Xcode. Both apps are running and are in the foreground. iOS app launches on iPhone and reports: WCSession.isSupported = YES theDelegate.session.isPaired = YES theDelegate.session.watchAppInstalled = NO theDelegate.session.activationState = Activated I press a button in the Watch app. It reports: session == activated and reachable iOS app delegate receives a message from the Watch app: didReceiveMessage (from Watch): message = {     action = giveMeUpdatedItems; } The apps must be installed on the devices in order for the Watch app to have used sendMessage (which is only available if the session is reachable, which it is). iOS app delegate passes that through as a notification to another bit of code that collates the info and sends it back to the Watch app. watchNotificationUpdateData; userInfo = {     action = giveMeUpdatedItems; } That bit of code in the iOS app checks whether we can send data to the Watch app, and doesn't send the data because: WCSession.isSupported = YES theDelegate.session.isPaired = YES theDelegate.session.watchAppInstalled = NO theDelegate.session.activationState = Activated If I remove the check for watchAppInstalled, I get this: Error sending Watch application context: Watch app is not installed. {     NSLocalizedDescription = "Watch app is not installed.";     NSLocalizedRecoverySuggestion = "Install the Watch app."; } I've deleted and reinstalled the app on both devices countless times. I've rebooted the devices, plus the Mac. I've reinstalled Xcode. I've cleaned builds. I've deleted DerivedData. And still it says the companion app isn't installed.

Hi there, I have two extension in my App, a Finder Sync and a Share Extension. Because these are disabled by default and automatically enabling them is, according to my extensive research, not possible, I want to provide an easy way for the user to enable the extensions when the app is opened. I am currently displaying a popup, with a button to open the preferences. I have struggled with this a bit, by now I managed to open the main preferences window using NSWorkspace.shared.open(URL(string: "x-apple.systempreferences:com.apple.preference")!) which is rather suboptimal though, since the user has to select the extensions option manually and isn't directly redirected there. What I have also found is that the menu of the FinderSyncExtension can be opened directly by using FIFinderSyncController.showExtensionManagementInterface() which is unfortunately suboptimal as well, because it only shows the managment interface of the finder extension and not the overview of all extensions. Is there any way to either enable the extensions programatically, or if not, is there a way to show the "Added Extensions" portion of the Extensions menu in the system preferences?

I recently raised this post explaining how I couldn't seem to get watchOS 9 complications to work, and I've figured out a partial fix. The original post details the issues with complications - and some are still valid - but this fix applies to both my complications and Home Screen / Lock Screen widgets. I was following the various WWDC 2020/2022 videos and the Emoji Rangers sample code, adding bits here and there, and assuming they were completely valid. Sadly, this bit of code in the widget's dynamic intents IntentTimelineProvider getTimeline really just banjaxed everything: // Create entries for one day, 15 minutes apart let currentDate = Date() for minuteOffset in stride(from: 0, to: 60 * 60 * 24, by: 15) { let entryDate = Calendar.current.date(byAdding: .minute, value: minuteOffset, to: currentDate)! entries.append(EventEntry(date: entryDate, event: event)) } If I remove that, and generate a different timeline with specific dates and times (for example: now, in 10 mins, in 2 hours, in a day, etc.) the complications appear correctly, as do Home Screen and Lock Screen widgets. The outstanding issues with complications are: The previews all use the same data, but getSnapshot() is supposed to return the data specific to that event from the configuration, i.e. if let theId = configuration.event?.identifier. "Christmas" is correct, but "Gallery Opening" is using Christmas's data. Once I've selected the event I want to use in a complication the edit screen shows it as totally blank, not even a placeholder: I hope this little fix works for you guys. And, if you know how to fix the above issues, let me know. (iOS 16.1 beta 1, Xcode 14.1 beta 1)

I found that almost all third-party applications cannot focus when they ask me to take an ID card photo. The same issue description from Twitter: https://twitter.com/mlinzner/status/1570759943812169729?s=20&t=n_Z5lTJac3L5QVRK7fbJZg Who can fix it? Apple or third-party developers?

I am running the watch on watchOS 9 and trying to enable "developer mode" (which requires a restart). However, upon restart, developer mode remains disabled. I tried several times, but developer mode just won't turn on. any thought how to solve?

I am playing around with Live Activities and got everything working on the iOS 16.1 beta 2 simulator using Xcode 14.1 beta 2 (14B5024i). However, running the same code on a real physical device (iPhone X) running iOS 16.1 beta 2 does not show the Live Activity on the lock screen at all. 😵 Did anyone get their Live Activity working on a real device yet, or is this an issue with the current beta? Things I have already checked: ActivityAuthorizationInfo().areActivitiesEnabled returns true on my physical device let activity = try Activity.request(...) successfully completes without throwing and I can see the activity.id printed to the console Other live activities - such as the iOS system timer activity - do show up on my physical device just fine