I know this is a five-year-old question, but I thought I'd point out that this method is documented as being meant to load a texture in an asset catalog, as opposed to an image in an asset catalog. (Make sure to choose "New Texture Set" when setting up the asset catalog.)

This took a little tracking-down, but it might be what you're missing: This WebKit blog entry implies that certain "activation-triggering user events" will grant "user activation," which the Web Audio API requires on iOS. But "touchstart" is not one of those qualifying events. The entry quotes the HTML spec as defining the following events as qualifying: keydown, excluding the Escape key and possibly some keys reserved by the browser or OS mousedown pointerdown, but the pointerType must be “mouse” pointerup, so long as the pointerType is not “mouse” touchend

An update. I've tried building an running an macOS app using only that example code from the documentation. Not only does the last date have no effect, but starting at the time it's expected to have an effect, Xcode's debug dashboard shows the app's CPU usage jumping from about zero to about 7 percent and staying there indefinitely. Profiling this in Instruments and digging into the traces seems to indicate that AppKit might be perpetually attempting to animate something, but of course it's difficult to know more than that. I can only conclude something's just really wrong with the TimelineView API when used with an explicit schedule. I'd love to hear any news or elucidation about this.

Hi, HulaBalooFl – The other code in your sample indicates you've set up a new project using SwiftUI, which is a modern app centred around a graphical user interface. In that situation, the system looks for an entry point which is a struct conforming to App adorned with @main with the intent of setting up the app's interface, and then calls code within those types at appropriate times. In other words, it doesn't really run the lines of a program "top to bottom" like a traditional coder might expect. If you're just trying to get to know the Swift language and run a sequence of lines in order with a printable output, you might want to start by choosing "New > Playground" and picking the "Blank" template, which just lets you edit and run code without building an app at all. Or perhaps, choose "New > Project" and then pick the "Command Line Tool" template, which lets you build an app without a graphical interface.

Thanks @Starfia, this appears to be a bug. Thanks very much for confirming that – at least it quiets my indecision about how to proceed. That advice just gives me a Content View that conforms to the detail column's resizable area, though, so I don't think it gives me the fixed-sizedness I'm looking for. The closest I've been able to come has been to hard-code the frame of the Navigation Split View itself, but that involves knowing the combined height of all views I might add to the detail column at all times (alongside which the unwanted safe area propagation persists), so it's a whole undertaking. I think for this iteration, I just have to avoid using NavigationSplitView or the Inspector; I have to implement alternatives to those provided functionalities, but the layout issues disappear the moment I sidestep them.

A fascinating update. I've tried adding the newly-introduced Inspector modifier, which I also intended to use in the app I'm making: import SwiftUI @main struct TestApp: App { @State var isShowingInspector: Bool = true var body: some Scene { WindowGroup { NavigationSplitView( sidebar: { }, detail: { ContentView() } ) .inspector(isPresented: self.$isShowingInspector) { } } .windowResizability(.contentSize) .windowToolbarStyle(.unified(showsTitle: false)) } } struct ContentView: View { let complaint = """ What's with the vertical space \ around me when I'm \ in a detail column? """ var body: some View { VStack(spacing: 0) { Text(complaint) .font(.title) .ignoresSafeArea() .frame(width: 300, height: 300) .background(.blue) } } } This time, SwiftUI apparently adds entire toolbar's height to the minimum height of the window again! Now the detail column's mysterious vertical space equals twice the height of the toolbar: It doesn't seem to matter whether the Inspector is applied to the Navigation Split View (in order to span the full window height) or to the Content View itself – the detail column's height is the same. These seem like such simple use cases for such strangeness. Am I missing something incredibly simple…?

For whatever reason, I'm getting the expected "2.0" with my Studio Display. (There's also pixelLength, which returns the length of one pixel in points.)

(Years later…) I'm trying to understand File Coordinators now and that seems like a good question. FileManager methods still work generally even without File Coordinators. The point of File Coordinators is to let multiple apps, or objects within the same app, communicate about the timing of such actions and avoid acting simultaneously. So the relevant question is whether this particular method takes care of file coordination for you, in the same way that NSDocument would if you were using it. I don't think it does, so I'm guessing you should still be supporting file coordination yourself.

I've done this for at least one app and had no problems. One main purpose of UIDocument is to facilitate multiple user-perceived files, of course, but there's no harm in using it simply to store a single file in the app's ubiquitous storage that you manage for the user. (The only real disadvantage I've hit is the inability to interact with the document from watchOS.)

Hi, Balvir, HTML is the primary language used to define a web page's contents. Every web page is written in HTML. CSS is a secondary language which is used to specify how the contents are styled and displayed. Web pages don't have to use CSS, but a web page that doesn't use CSS will appear similar to a common text document, with default fonts and colors. WebKit is the rendering engine built into Safari and some other browsers. Its job is to read HTML and CSS and properly display the web pages they define. You don't need Xcode or Swift Playgrounds to make a web page, because HTML and CSS don't have to be compiled. You can even write a web page in TextEdit, save the file as an HTML file, and open it using Safari. Here's an example of a simple web page written in HTML: <!DOCTYPE HTML> <html> <head> <title>The best web page!</title> </head> <body> <p>This is a great web page.</p> </body> </html> I suggest searching for tutorials on writing your first web page. There are lots!

Thank you – that's about what I was expecting. ^ ^

Just to add my experience for anyone finding this thread later – I had a similar non-descriptive "abort trap" error when compiling my own project. In my case, I'd added a possible call to fatalError() in one of my classes' initializers during an experiment – it looks like that was enough to bring it about. Removing that branch was enough to get back to where I was before the error ever showed up.

I've been getting persistent beach balls in Xcode version 12.3 and 12.4. For me, the culprit has always turned out to be my connected iPhone – I can either wait out the current beach ball and unpair it in the Devices window, or I can simply disconnect the Lightning cable and the beach ball stops immediately. Yikes.

Whoa! The solution from mark-e-mark was the correct one in my case. Thank you so much – I would never have found that, and I don't think Xcode made any attempt to suggest it.

Okay, I'm working things out. As seems to be the case with much of Game Center, there seem to be design intentions belied, rather than explained, by the documentation.To set up a match with the Local Player's friends, there's no need to use identifiers at all – I'd just missed the one method that still returns GKPlayers for friends: `loadRecentPlayers`. Its name doesn't mention friends, but there's an afterthought in the documentation which mentions it also returns players from the "legacy friends list." (I wonder how it's "legacy" – you can add people to it in iOS 13.)gamePlayerID and teamPlayerID appear to work: you can access them and store them. But for players other than the Local Player, they seem, intentionally, not to persist between app launches or connections to Game Center. They change every time. Apparently they just can't be used for data persistence in the way playerIDs could be.