Suppose I make a UIFont like this: let variations = myCustomVariationsDictionary     let key = kCTFontVariationAttribute as UIFontDescriptor.AttributeName     let uiFontDescriptor = UIFontDescriptor(fontAttributes: [.name: Self.name, key: variations])     let updatedUIFont = UIFont(descriptor: uiFontDescriptor, size: uiFont.pointSize) self.uiFont = updatedUIFont —thereby creating a variable font in RAM and saving it to some object. How do I then register that created font in the CTFontManager such that we can access it by name from SwiftUI? The variation name doesn't correspond with any font file on disk; it will be something crazy like "RobotoFlex_wght0BADF00D_YXCD8282384729" (or whatever) and will be different based the values used for each of the variation axes. The problem I'm facing is that you have to specify the font size when you create a given variable font, or UIFont instance. Now, that font is baked in at that particular size, which might not be the appropriate optical size for the final size it might scale to as a result of DynamicType (e.g. as with an @ScaledMetric for the size). But we can't have the wrapper around the CTFont methods use @ScaledFont property wrapper, since this wrapper does nothing unless used on a conformance to View that's actively being used in an actual SwiftUI graph. In other words, it seems like we have to dynamically recreate the font every single time we want to use it in a Text view, which causes all kinds of nasty memory leaks and unbounded growth of RAM not to mention horrible performance. I've looked at various options available in github—there's exactly one SwiftUI wrapper around dynamic fonts, and it's very uninspiring. So here I am, asking you lot for any advice. Really, I prolly need to file a DTS ticket, but figured I'd try here first. Thanks!

In iOS 15 SDK you added the new FocusState API in SwiftUI. However there is no discussion or explanation anywhere that I could find, which explains: What exactly is "focus"? What isn't focus? What is the relationship between FocusState and accessibility focus? What is the relationship between whether a SecureField is being edited, and whether it's "focused"? Example: Lets say my tvOS app has an on-screen keyboard, where the user uses the remote's directional controls to move focus around to the letter buttons. To enter their password, they focus the password field, then click the center button to activate it. Now that it's active, they move focus to each letter of their password and click on each one: P... A... S... S... W... R... D... !... then they move focus to the "Submit" button and click. In this case, while the SecureField is being edited, focus moves around to a bunch of different buttons. The point of this example is that, if SecureField had a public "isBeingEdited" property, then it would be TRUE even while the field is not focused. However most Workday's designers interpret "focused" as being totally equivalent to "isBeingEdited" because in a web browser, tabbing out of a field makes it stop being edited. What is Apple's intent here? When not using a remote or physical keyboard or screen-reader, how is focus supposed to relate to whether a field is being edited? Does this relationship change when a user now has a bluetooth keyboard connected and Full Keyboard Access is turned ON? How does this correlate with accessibility focus? I cannot find any documentation from Apple that explains what focus is, or how this is supposed to work in SwiftUI in the various different scenarios where the concept of "focus" is relevant. Do you have a link to something current that explains how it's supposed to work so that we will know if there's a bug? Last question: how can we make the iOS simulator treat the physical keyboard as if it was a bluetooth keyboard to be used for focus-based keyboard navigation?

How do you modify container views in SwiftUI? For example, a sheet or popover. These views have a particular shape and different properties on how they can be customized in iOS, iPadOS, macOS, etc. However it seems that they're only available as modifiers on another view. Can someone explain why that should be the case? Like, why should a popover only be available as a .popover modifier, which does not actually modify the view that you apply it to? From what I can tell, because .popover and .sheet are only given as modifiers (but not as an actual view struct), there seems to be no way to modify how the presentation container itself looks. For example, SwiftUI gives none of the normal customization for a sheet, such as the corner radius, detents, dimming behavior, etc. Am I missing something here? Why would Apple leave this stuff out? Can someone explain why Apple has chosen to have .sheet or .popover as modifiers, even though: it doesn't actually modify the view you're applying it to it means you cannot modify the sheet or popover itself because any modifiers you apply will affect the same thing the .sheet or .popover or .alert modifier (etc.) applied to For example, not even the font of a button in an .alert can be changed, even though it lets you try: Text("I am not actually being modified at all.) .alert(Text("My font won't be affected by any modifiers.").font(.myFont), isPresented: $isPresented) { ... } This compiles just fine, but the font modifier has no effect. I feel like I must be missing something here... am I? Does SwiftUI have a solution for us, other than writing custom wrappers around the UIAlert/AppKit/WatchKit stuff? If not, do we know why not? Like... is Apple is deliberately choosing to make SwiftUI this limited, or is this what they could do within the time that has elapsed so far? Thanks for any insights/tips. Note: I'm not against wrapping UIKit/AppKit/WatchKit but would like to make sure that I'm understanding how the API is designed to be used so that whatever custom APIs we craft would match the spirit of SwiftUI as closely as possible. The main thing I'm having trouble with is understanding why modal containers are not first-class citizens that you can apply view modifiers to. I have done a lot of research into various alternate repos and strategies, but just trying to make sure there's not something that we're all missing here.

We're experiencing an extremely bizarre crash in our iOS/iPadOS app. Some major changes in our latest release: Built with Xcode 13 on Big Sur 11.6 Added Hardened Runtime entitlement Enabled Hardened Runtime in build settings Dropped support for iOS 13 Updated Firebase to 8.8.0 Built using the latest fastlane version OK here's the bizarre part: our app works fine for users who download and install the app directly from the App Store, on both iOS 14 & 15. However, iOS 14 users who get the app pushed to their phone by MDM and install it from a dialog box like this will have it crash on launch: So what is the difference between launching the app after installing it yourself, and launching it after MDM installs it—in both cases, the app originates from the App Store? Here is an example crash log: {"app_name":"REDACTED","timestamp":"REDACTED","app_version":"REDACTED","slice_uuid":"REDACTED","adam_id":REDACTED,"build_version":"REDACTED","platform":0,"bundleID":"com.REDACTED.REDACTEDapp","share_with_app_devs":0,"is_first_party":0,"bug_type":"109","os_version":"iPhone OS 14.6 (18F72)","incident_id":"REDACTED","name":"REDACTED"} Incident Identifier: REDACTED CrashReporter Key: REDACTED Hardware Model: iPhone11,8 Process: REDACTED [1561] Path: /private/var/containers/Bundle/Application/REDACTED/REDACTED.app/REDACTED Identifier: com.REDACTED.REDACTEDapp Version: REDACTED AppStoreTools: 13A1030d Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition: com.REDACTED.REDACTEDapp [562] Date/Time: 2021-10-26 15:17:43.5707 -0500 Launch Time: 2021-10-26 15:17:43.1390 -0500 OS Version: iPhone OS 14.6 (18F72) Release Type: User Baseband Version: 3.04.01 Report Version: 104 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000115596b28 Termination Signal: Segmentation fault: 11 Termination Reason: Namespace SIGNAL, Code 0xb Terminating Process: exc handler [1561] Highlighted by Thread: 0 Backtrace not available Unknown thread crashed with ARM Thread State (64-bit): x0: 0x000000016d11d5c0 x1: 0x0000000000000008 x2: 0x0000000000000000 x3: 0x0000000000000000 x4: 0x000000016d11d590 x5: 0x0000000000000020 x6: 0x736665727373616c x7: 0x0000000000000600 x8: 0x000000005f24901f x9: 0x000000000f8884a0 x10: 0x000000000000901c x11: 0x0000000000000003 x12: 0x0000000000ff0006 x13: 0x000000000000c000 x14: 0x0000000000000001 x15: 0xffffffffffffffff x16: 0x00000001030879cc x17: 0x6ae100016d11d440 x18: 0x0000000000000000 x19: 0x0000000115596b28 x20: 0x000000016d11daf8 x21: 0x000000016d11dad0 x22: 0x0000000105d00000 x23: 0x000000000f896b28 x24: 0x000000005f24901f x25: 0x0000000105d0e680 x26: 0x000000000000e688 x27: 0x000000016d11db08 x28: 0x0000000000001b99 fp: 0x000000016d11d6a0 lr: 0xba6bf2010306bf84 sp: 0x000000016d11d620 pc: 0x000000010306beec cpsr: 0x00000000 esr: 0x00000000 Address size fault Binary images description not available Error Formulating Crash Report: Failed to create CSSymbolicatorRef - corpse still valid ¯\_(ツ)_/¯ EOF We don't see these crashes appearing in Crashlytics. I'm not sure if they're appearing in Xcode organizer, but if they are I haven't been able to find them. I can reproduce the crash locally using our UEM test account for VMWare Workspace One (AirWatch), but it does not happen on AdHoc or Developer builds, nor does it happen if Xcode is connected with a live debugger session. We tried regenerating all our provisioning profiles with DER encoding, then re-signing and re-submitting the app to Apple, but it did not help the problem. Any tips would be most appreciated as we are extremely befuddled by what could possibly be causing this.

It seems Xcode 13.1 RC requires the unreleased macOS 12. Will this requirement also affect the official release of Xcode 13.1? Traditionally Apple has always waited until mid-cycle (Feb./Mar.) before releasing an Xcode update that requires the latest macOS. For example, Xcodes 12.0 through 12.4 on Intel Macs would work on Catalina. It wasn't until Xcode 12.5 that we finally had to all be on Big Sur. However now it seems Xcode 13.1, which is now in RC, will require us to already be on macOS 12 Monterey. Is that correct or does that requirement only affect Apple Silicon users? If it does indeed affect Intel Macs as well, this could be a huge blocker for many of us who work within large enterprise and use managed computers. For example, I have to wait until my corporate IT department officially supports the new OS before I can update my Mac to it. It usually takes them three or four months after a new major macOS release to roll out an update to all our Macs, due to the usual delays in how long it takes our anti-malware suppliers and all the validation and testing our IT department performs on the updated system image before major updates. That means if Xcode 13.1 requires Monterey on Intel Macs, we're going to be blocked from updating to the latest Xcode for quite awhile, which is problematic because (if Xcode 13.1 behaves like all the past updates we've seen) it means we won't be able to debug our app with devices running latest iOS versions. Please advise, thanks!

Our snapshot tests are encountering "Error: Failed to set device orientation: Not authorized for performing UI testing actions" when we call XCUIDevice.sharedDevice.orientation = UIDeviceOrientationPortrait or similar. From a post on Flutter's GitHub issues, I gather that this error is new in iOS 15 SDK / Xcode 13. Now it seems unless you're actually running XCUITests, you cannot change the properties of XCUIDevice.sharedDevice.orientation. OK, but if that's the case, how do we change it then? I tried to look for WWDC videos on this subject, but the link for the WWDC session "Create Great Tests With Xcode 13" does not have a video or anything. https://developer.apple.com/news/?id=5mm81ukv Why is this video missing? Details of the exception: Exception _XCTestCaseInterruptionException * 0x60000082b060 0x000060000082b060

Background Xcode Test Plans, which debuted in Xcode 11, feature the ability to designate an .xcappdata bundle to copy into the test host app's container before tests run. (Before Test Plans, you could do the same thing by designating an .xcappdata to use on a per-target basis by editing the Test area of a Scheme.) The UI for designating the .xcappdata to use for a given test target within the .xctestplan editor in Xcode 13 Back in Xcode 5 and prior, whenever you'd run your tests on a simulator or device, Xcode would copy the .xcappdata over to the simulator or device before the host app is launched for each test run. However Xcode 6 introduceda bug where the .xcappdata does not get copied over to the simulator. Ever since then, from Xcode 6 through 13, .xcappdata is only copied over when you're running tests on a physical iOS device. Current Workaround Oddly, although Xcode itself doesn't handle copying the .xcappdata to a simulator, the terminal command xcrun simctl provides the ability to install an .xcappdata bundle to a given simulator or erase a given app's container. Based on this, the workaround we're using is that I wrote some custom fastlane build scripts for our current Jenkins-based CI system, which sets up each simulator ahead of running the tests. And for local builds in Xcode itself, we have a pre-test action that runs a script to install the .xcappdata to the simulator. Of course, we shouldn't have to implement these kinds of workarounds—it should just work. Apple shouldn't leave a glaring bug like this in Xcode for 5 years without fixing it. Question In the WWDC talk, "Explore Xcode Cloud workflows," it is stated: Xcode Cloud provides a recommended option, which is a collection of simulators with different screen sizes This indicates that, in Xcode Cloud, tests run in simulators, not physical devices. Given that the above bug is still in Xcode 13, in Xcode Cloud, how are we supposed to run test plans that specify .xcappdata bundles for particular test targets? Without this bug being fixed, the simulators won't have the .xcappdata bundles loaded into them, and the tests will always fail. Given that the scripts that install .xcappdata to a simulator have to know the name of the simulator and have write-access to the directories where the simulator containers are stored, I'm a bit concerned about how feasible it would be to use a workaround similar to the one we're currently using. It seems to me it would be far preferable if Apple would simply fix this long-standing bug. But I am curious to hear what Xcode Cloud team has to say about it. BTW I still have an open DTS ticket and FeedbackAssistant ticket on this issue with no resolution: DTS ticket #765312786 Feedback Assistant issue: FB9070373 (from me) Feedback Assistant issue: FB9127508 (from Github user @imWildCat, aka Daohan Chong of Microsoft) Other references: Apr. 2015 StackOverflow: Xcode is not loading the .xcappdata into the app Apr. 2015 Open Radar 20622011: Xcode 6.3: Cannot use xcappdata package in simulator Aug. 2015 Open Radar 20481684: Xcode never copies the application data specified in a schema to the simulator Oct. 2015 Open Radar 23336152: Xcode 7.1: Cannot use xcappdata package in simulator Nov. 2015 Open Radar 23500433: Custom application data is ignored when launching app in iOS simulator Thanks.

What's the difference between "isEditing", "focus", and "accessibility focus" in SwiftUI in iOS 15 SDK? In iOS 13/14 SDKs, using a hardware keyboard, you can focus a different field than the one you're currently editing. One of the main difficulties in SwiftUI that we've had for iPad has been how to manage these kinds of situations, since for example, with SecureField, there's no hook for when it starts editing or when it becomes focused. So we had no way to customize the focused appearance of SecureField or even, programmatically set focus to password field if it had an error, scroll the view to make sure whichever field is now focused in visible, etc. We found that "isEditing" and "isFocused" are two completely different things in iOS, and there's a third thing—"accessibility focus" which also needs to be kept track of. "Keyboard focus" is when you have a physical keyboard and you use tab to select a different field—this allows you to focus a different field than the one that's currently being edited! But in the new SwiftUI "focus" system, it sounded like "isEditing" and "focused" are now being treated as the same thing? Is that correct? Can you no longer focus a different field than the one that's being edited with a keyboard? Is accessibility focus still a different thing?? Please clarify thanks!

We have 75 Mac Pros in our own corporate datacenter that currently run our Jenkins instances for CI/CD. Can we repurpose these to serve as Xcode Cloud nodes for our builds, or does Xcode Cloud require that the builds occur on Apple's machines? If it must be done on Apple's hardware, who is a security contact at Apple who we can get our security team in touch with to vet the Xcode Cloud service? Thanks

I set up a new test target for my app useing Xcode Test Plans to specify an .xcappdata file to use for each target. We run the tests in iPad & iOS Simulators, which get recreated from scratch prior to each test run. However, Xcode never actually copies over the app data (such as com.ourCompany.ourApp.plist, and other files) from the .xcappdata file into the appropriate directories of the simulator container in ~/Library/Developer/CoreSimulator/Devices/SIMULATED_DEVICE_GUID/data/Containers/Data/Applications/OUR_APP'S_CONTAINER_GUID/. So our tests fail because, for example, a fresh app .plist gets generated instead of using the one from our .xcappdata, resulting in UserDefaults settings values not matching expectations. Am I doing something wrong? How can we get this to actually work...? I have found multiple other threads, such as this one on Apple Dev Forums from four years ago - https://developer.apple.com/forums/thread/43719?login=true&page=1#668295022, and several on Stack Overflow such as this post - https://stackoverflow.com/questions/47684823/including-application-data-in-ios-simulator, that indicate that this feature has been broken since at least Xcode 6. But... didn't they just add the per-target .xcappdata feature as part of Test Plans in Xcode 11? How could it already be broken again in Xcode 12.3? Does Apple not to have tests around their own Test Plans feature? I hope someone can enlighten me... is it a permissions issue? A regression due to Big Sur? Do I need to add some cryptic executable (buried within the uncountable subfolders in /Applications/Xcode.app/Contents/Some/Deeply/Nested/Toolchain/usr/bin) into Security & Privacy Privacy Full Disk Access? Any help would be much appreciated... thanks! I did find the following workarounds, but neither seems very scalable: set the HOME and CFFIXED_USER_HOME environment variables to $(SRC_ROOT)/path/to/myData.xcappdata/AppData/ in the test scheme (this causes that folder to now become the simulated app's container directory, resulting in these files getting modified as a result of the tests running with this as their actual home instead of the usual container location!) use a script to copy over the files from the subfolders nested inside .xcappdata into the same subfolders that are nested inside of ~/Library/Developer/CoreSimulator/Devices/SOME-GUID/data/Containers/Data/Applications/ANOTHER-GUID/ (of course since these GUIDs are random and determined at test time, how to write such a script and get it to work reliably on both CI machines [that execute tests using Fastlane scripts] and local developer machines [that execute tests from within Xcode], would be pretty annoying)

Is Apple going to fix Xcode before 12.5? Is there going to be a beta 4? Swift Package Manager integration is still hopelessly broken in Beta 3. Targets with .binaryTarget still don't build in time to be linked with other targets; dynamic targets still build as static targets causing build errors; SPM still does deep clones of source repos making it take forever... (adding Firebase to our project takes 15 minutes before the UI is responsive and incurs a 20 minute delay to open the project without a cache).

In Xcode 12.3 the list of prior simulator versions is empty, making it impossible to download prior iOS simulator versions. How can I fix this? Or is it just an endemic bug that Apple allowed to slip into the release of Xcode 12.3? Both myself and another engineer at my company have experienced the same issue. We are both on Catalina 10.15.7 (19H114). We both installed Xcode 12.3 when it was in RC, but it's the same exact build as the official release (12C33).

Our fastlane Xcode builds are failing intermittently when run by Jenkins. About 10% of builds, while running test targets, we'll get a failure with: [2020-11-16T16:12:10.276Z] 2020-11-16 08:11:47.435 xcodebuild[72478:2549553] [MT] IDETestOperationsObserverDebug: 415.317 elapsed -- Testing started completed. [2020-11-16T16:12:10.276Z] 2020-11-16 08:11:47.435 xcodebuild[72478:2549553] [MT] IDETestOperationsObserverDebug: 0.000 sec, +0.000 sec -- start [2020-11-16T16:12:10.276Z] 2020-11-16 08:11:47.435 xcodebuild[72478:2549553] [MT] IDETestOperationsObserverDebug: 415.317 sec, +415.317 sec -- end [2020-11-16T16:12:10.276Z] Testing failed: [2020-11-16T16:12:10.276Z] REDACTED_iPhoneTests: [2020-11-16T16:12:10.276Z] REDACTED.app encountered an error (Failed to install or launch the test runner. If you believe this error represents a bug, please attach the result bundle at /tmp/build/jenkins-mobile-ios-develop-1107/ios/fastlane/output/derivedData/Logs/Test/Test-iPhoneSnapshotTests-2020.11.16_08-04-51--0800.xcresult. (Underlying Error: The request to open "com.REDACTED.REDACTEDapp" failed. The request was denied by service delegate (SBMainWorkspace) for reason: Busy ("Application cannot be launched because it has outstanding termination assertions"). (Underlying Error: The operation couldn’t be completed. Application cannot be launched because it has outstanding termination assertions.))) In the simulator device logs we have a lot of "failed to bootstrap path" errors, where the report indicates that some path under Xcode-12.app cannot be found (even though in reality, it's there): Failed to bootstrap path: path = /Applications/Xcode-12.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/dyld_sim, error = 2: No such file or directory Nov 16 08:11:44 Mac-169 com.apple.CoreSimulator.SimDevice.4A33E878-D3F6-4EE4-AB53-7ACD59E0B8A5[73117] (com.apple.xpc.launchd.domain.pid.testmanagerd.73149): Failed to bootstrap path: path = /Applications/Xcode-12.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit, error = 2: No such file or directory Nov 16 08:11:44 Mac-169 com.apple.CoreSimulator.SimDevice.4A33E878-D3F6-4EE4-AB53-7ACD59E0B8A5[73117] (com.apple.xpc.launchd.domain.pid.LogArchiveCollector.73942): Failed to bootstrap path: path = /Applications/Xcode-12.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/dyld_sim, error = 2: No such file or directory Nov 16 08:11:44 Mac-169 com.apple.CoreSimulator.SimDevice.4A33E878-D3F6-4EE4-AB53-7ACD59E0B8A5[73117] (com.apple.xpc.launchd.domain.pid.LogArchiveCollector.73942): Failed to bootstrap path: path = /Applications/Xcode-12.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit, error = 2: No such file or directory

How can we programmatically disable the app-specific localization setting from Settings.app > MyApp (feature that was introduced in iOS 13)? The problem is, our app receives a localization preference sent by the server after the user logs in. The initial loading screen of the app would use the device's default language/region, but after the user logs in, we switch to whatever the user's account-level language/region settings are (as provided from our remote server). The reason we do this is because our app is used in settings where multiple users share a single device, but they don't all speak the same language. It's assumed that the owner of the device dictates the login screen language by setting up the device with a particular language. And then after a user logs in, they get an experience that is tailored to their specific language. We don't want to require each user to have to switch to the Settings app in order to switch the language every time they log in. Please advise, thanks!

Why is Xcode 12.0.1 only available via Mac App Store?