You're complying with all the requirements in 5.4? Registered as an organization and not an individual, use NEVPNManager, have the appropriate declarations about data collection in the app, etc? What is the app using a VPN for or claiming that it can be used for?

I was running into this a couple of weeks ago and finally got it to accept a password of the formUj28-Bky1-J1sK-19Sn(four groups of four random letters/numbers, separated by dashes). I've no idea what the real requirements are, but someone in a different thread mentioned that it was probably unhappy with the password, so I was just trying different ones.

Maybe just iterate through everything in the scene's children field and print out names, at least for debugging. (The code as written might well crash if it had found the button, since SpriteKit doesn't like addChild when the added node already has a parent.)

Not that it's necessarily the issue at the moment, but you will soon be required to offer Sign in with Apple as well as sign in with Facebook (unless your app falls under one of the exemptions).https://developer.apple.com/app-store/review/guidelines/#sign-in-with-apple

As discussed in various stackoverflow threads, physics bodies from textures was completely broken in 13.0 and 13.1. It was partially fixed in 13.2 in that it works for textures that are not in atlases. I haven't checked 13.3 specifically yet since we worked around the issue by adding duplicate not-in-atlas versions of textures just for making physics bodies (and by falling back to a convex-hull approach when running under 13.0 and 13.1). As a suggestion to try to get something working, see if you can remove anything that needs a texture-based physics body from an altas.

We don't use sks files but do everything programmatically, so I don't know what might be happening under the hood there. Unfortunately I only have two physical devices, one with iOS 12.4 and one now with 13.3. I can't say for sure whether the issue has to do with the device's iOS version or with the Xcode version and libraries instead, but our code has two paths when making a physics body. One for iOS 13.0 and 13.1 where it uses a convex hull, and one for everything else where it uses the texture but not from an atlas. Upgrading from 13.2 to 13.3 didn't break it, so I assumed 13.3 was at least as working as well as 13.2 when it came to making physics bodies. I also assumed a 13.1 device would still be broken, but don't have one to test. Simulator testing never showed a problem, but it wasn't practical in our case.

body A category = 0001, contact = 1001body B category = 0101, contact = 1000(Body A category) bitwise-& (body B contact) = 0000, would not flag collision(Body B category) bitwise-& (body A contact) = 0001, flags collisionAccording to the documentation, if either comparison gives a nonzero result, you'll get a collision notification.https://developer.apple.com/documentation/spritekit/skphysicsbody/1519781-contacttestbitmaskIf you don't want that notification, you have to make sure that body B's category mask does not overlap with body A's contact mask.

Uint32(5) bitwise-& Uint32(9) = Uint32(1). Because that result isn't 0, it's notifying you of the collision.If you don't want that notification, you have to either change B's category bitmask or A's contact bitmask.The fact that the overlap between A's category and B's contact is 0 doesn't matter, since it notifies you if either result isn't 0.

The iPhone X is driving a display of about 2400x1100, the 6s only about 1300x750, so differences in FPS aren't that surprising. Your main problem is likely the enormous number of draws: a whopping 120 for only 300 nodes. Perhaps you're using a lot of shape or text nodes, or maybe you've got a bunch of sprite nodes whose textures aren't in an atlas, or maybe you have ignoresSiblingOrder set to false unnecessarily. Once you fix the draw count issue, your performance will probably be much better on both devices.

FWIW, we wound up not using the logo due to consistency with the app settings screen (where there's a Game Center achievement reset button but the regular GC logo color scheme looked inconsistent), so I never found out whether it would have passed review or not. We did write to legal, but we're probably too small for them to worry about and they never responded.

I decided to keep using playerID for now, and to stash away a mapping between that and gamePlayerID/teamPlayerID when scopedIDsArePersistent indicates that those are not transient. I'll figure out how to transition data associated with playerID when/if clarity is provided.

There are a few earlier threads on this forum and various threads on Stack Overflow discussing issues with physics bodies from textures in iOS 13.*. I'm not sure that those are all fixed yet (I worked around them back when the latest was 13.2 and haven't gone back to see the story in 13.3), so perhaps that has something to do with your contact issues. On the other hand, when I was having problems, showsPhysics would display obviously-broken physics body outlines.I've had no other issues though, despite working extensively with a large portion of the SpriteKit API over the last half year. When stuff like logging messages don't show up, it seems like something much odder is going on.

The actions will get run sequentially on your main thread, but sticking stuff in didMove may not be what you want. The only thing I ever used there was an initial action to happen on scene appearance (e.g., to wait for a couple of seconds, then start a new game). And things like background nodes that have something like an infinitely repeating animation could be placed there, though I usually put those in the scene creation. But once the scene gets going then the actions are all scheduled from other places. E.g., in response to contacts between nodes, or from the update function, or triggered as a result of user interaction, or based on completions of other actions, etc.Maybe you need to provide more context, because it's really not clear how you have things structured.

It's hard to say without being able to try it and see what happens, but my impression is that you're essentially setting up a bunch of nodes in one corner, scheduling actions to have them move (in parallel) into position, renaming two nodes, and then scheduling actions to have them do some rotation (also in parallel with everything else). I suspect you want things to happen in a more sequential order:1. The shapes start in a corner and spread out to form an array (perhaps in parallel, perhaps one-by-one).2. One corner node to do some rotating.3. The second corner node to do some rotating.Possibly you want 2 and 3 to happen in parallel, but in any case, from your description it sounds like 1 should definitely happen before 2 and/or 3. That's not what you've written though.In particular, lines 28-38 add a bunch of nodes, schedule actions for those nodes, and then immediately (before the actions run) do the renameShape stuff.The completion of the run action means the completion of adding the nodes and scheduling their actions, but it does not mean the completion of those scheduled actions.There are various ways of sequencing things. E.g., you could pass a completion block that would do the rotations and have addShape schedule that after the completion of the actions for one of the nodes (assuming they all move into position simultaneously). Or you could just have another action that would wait(forDuration:) a bit longer than what it takes the nodes to move into position and then runs a block to do the rotations.As a side note, when you're writing SKAction.group, those are happening in parallel. So in a group with actions that have duration 2, an action that is a delay of 0.1 is having no effect at all. Maybe you meant SKAction.sequence, or .sequence([.group([...]), .wait(..)])

Oh, also sequences like NSLog, run, NSLog are just going to do two log messages in quick succession. It's not waiting for the run to finish. If you want that effect, you need to have the second NSLog in a completion block for the run.