Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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…?
Post not yet marked as solved
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.)
Post not yet marked as solved
(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.
Post not yet marked as solved
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.)
Post not yet marked as solved
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. ^ ^
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
Agreed – I think for now I just have to proceed as though the scoped IDs weren't announced yet.
Post not yet marked as solved
Obviously relevant at the moment.I'm attempting to finalize my first Game Center game after years of watching the APIs, and I'm not succeeding in finding out how to use the new scoped IDs while avoiding playerID entirely. For example, I can't see there's even one available pattern for obtaining scoped identifiers for the local player's Game Center friends in order to invite them to a match. Meanwhile, the existing methods for this pattern – obtaining and using a playerID to form a match request – appear to have been deprecated as well.I get the feeling WWDC 2020 is going to bring a wave of clarity along with some of this seemingly unreplaced functionality, and that the video presentation about the scoped identifiers are more of a sneak peek than a true call for conversion to what will replace it. But that's entirely inference, and that clarity seems merited at the mention of these new APIs and deprecations.
