Posts

Post not yet marked as solved
1 Replies
It seems to be related to safe areas as it doesn't happen on Touch ID devices.
Post not yet marked as solved
7 Replies
Still an issue in Xcode 15.3 (15E204a).
Post not yet marked as solved
2 Replies
I guess the property should be read-write, otherwise it would not make sense for it to exist. I wonder if we can get Apple's opinion on this, probably a bug report for this would be a good start.
Post not yet marked as solved
22 Replies
I'm experiencing similar issues, e.g. teamPlayerID and gamePlayerID are both "UnknownID". This just started happening between 2 devices and 2 GC accounts that used to work (my own devices and accounts). Not sure how to fix this so I'm wondering if there's any response from Apple on the bug reports reported by @RajDoshi.
Post not yet marked as solved
25 Replies
It seems that Xcode 14.1 doesn't ask to install Rosetta anymore.
Post not yet marked as solved
3 Replies
Looks like there is more to SKView.showsFields. When showsFields is true, if you have an SKFieldNode.customField({}) in the scene, the custom block is called for what appears to be physics bodies to the far top right, with different positions, zero velocity, 1.0 mass, 0.0 charge. Same, this can be easily replicated using the Game Playground, by adding an SKFieldNode.customField({}) with a block that prints out the arguments. If SKView.showsFields is false, the block is not called, as it should be. Feedback report has been updated but there's no update on it.
Post not yet marked as solved
5 Replies
Same problem here. Has anyone found any workarounds to this issue?
Post not yet marked as solved
4 Replies
Yes, what I meant is being able to run/test apps on devices running iOS 15.4+, or on the simulator running those versions. Basically you won't be able to use iOS 15.4+ SDKs at all while developing. This is definitely not good. A 2014 Macbook Pro is totally capable of running Monterey. Even more so that the 2014 Mac Mini is still supported by Apple to update to Monterey. A decision that is really hard to understand... Thanks for your reply.
Post marked as solved
1 Replies
The solution is to use an id on the GameScene and send it to the SpriteView with the .id() modifier, to force SwiftUI to create a new SpriteView. class GameScene: SKScene, ObservableObject { var id = UUID() } SpriteView(scene: scene, isPaused: paused).id(scene.id) This question was answered on SO: https://stackoverflow.com/questions/69610165/spriteview-doesnt-pause-scene-on-state-change/69610906#69610906 by @jnpdx.
Post marked as solved
4 Replies
Any update on this warning?
Post marked as solved
2 Replies
Thanks a lot @OOPer. It works as intended. One more related question. To track the paused state inside of the SpriteKit scene, I guess the best option would be to call a method on the scene, maybe in the onChange(of:perform:) modifier? var body: some View {     ZStack {       SpriteView(scene: scene, isPaused: showingLevelChooser)         .ignoresSafeArea()       VStack {         Button("Level Chooser") {           showingLevelChooser.toggle()         }         Spacer()       }     }     .sheet(isPresented: $showingLevelChooser) {       VStack {         Button("Cancel") {           showingLevelChooser.toggle()         }         Text("Level Chooser")       }       .background(BackgroundClearView())     } //↓     .onChange(of: showingLevelChooser) { value in       scene.isPaused(value)     }   }