Just in case anyone else runs into this problem, here's what I found... Using the StoreKit configuration that is provided in Xcode, you can test subscriptions in the simulator with no problems. However, trying to connect to the store and pull down IAP products on the simulator DOES NOT work. Switching to a physical device, it will quite happily pull down in-app purchases even though the app itself has not been submitted for approval.

Thank you for your amazingly detailed reply. TBH, I've never really kept up with the advances in the Network framework (all my day-to-day dev work so far has been invoking standard REST APIs using URLSession), so I kinda assumed it was just a newer version of CFNetwork which seemed pretty low level for my needs. After watching the videos you linked me too and had a look through the sample project, it very much seems like I can get a loooong way with the Network framework - stuff like the protocol framing looks really neat and relevant. I'll definition be starting there for some of my early prototyping. Thanks so much. One quick sidebar: ... as it's VERY difficult (basically, impossible*) to establish reliable connections between "everyone" on the internet The good news for me is that fully remote connections is actually an anti-goal for my game... my idea here is actually that this game is designed around the idea that players are physically co-located in the same room... which should remove (hopefully) a lot of the technical networking hurdles. Thanks again

Re: "So, I guess my question is whether I should just add a gesture recognizer to my custom button class? Is this inefficient if I end up having 7-8 buttons on the screen and each one has its own gesture recognizer?" Yes and no I've been testing a few patterns and I think I'm coming to the conclusion that I'll end up having a single recognizer in each scene that finds/hands-off to the appropriate button. I was kinda hoping to compartmentalise it so that each button is able to deal with that but it feels like I'm fighting the framework if I do that. Re: "what gesture recognizer lifecycle management do I need in a SpriteKit scene that is presented within a SpriteKitView?" I'll assume you're referring to SpriteView, and like a typical SwiftUI View you add a .gesture modifier. Sorry, I was a bit vague there... I was more talking about how the general guidance for gesture recognizer lifecycle is to add them to the view in didMove(to:) and then remove them just before transitioning to a new scene. Is this still the advice in a SwiftUI world? It seems so, but I wasn't sure if this had changed over time with the introduction of SwiftUI containing views. Do your buttons have to be rendered in the SpriteView or could they be in a container View instead as a Button? You might find this separation of concerns cleaner, and possibly improves MVC clarity. This was definitely one of the options I was exploring too. For the buttons that are a bit "chrome"-like, it kinda makes sense... but for the "in-game" buttons, it would mean splitting the game behaviour across SpriteKit and the hosting UI container (which I think would end up causing me more pain) Do you really need SwiftUI for building a SpriteKit game? Nah, definitely not. Xcode just happened to generate SwiftUI for me when I created the project. As it turns out, I'm not really "using" SwiftUI capability at all... it is just a dumb container for my scenes. Many thanks for your feedback. Much appreciated.

Thanks for the detailed reply. At the moment, for simplicity's sake, I'm inclined to just use the first one and just ignore any subsequent results... but I'm curious if there's a reason why subsequent results might be "better"? ie. let's say I decide to debounce to catch the later ones, what is better about the later ones that makes it worth doing that little bit of extra debouncing? Thanks also for the pointer to the Device Discovery framework... I did initially look at that, but sadly my game is designed to have multiple clients connecting to the Apple TV, so I think that rules it out. . ... peer-to-peer Wi-Fi, which has significant limitations in practice. I don't suppose you happen to have a link to a tech note, or a previous post, that might outline a few things to watch out for? Thanks again for your support - not just here, but in all aspects of the Apple ecosystem.

Just a quick note on @anelad's sample code above... this has made my clean up behaviour MUCH more robust. Previously, having my client just cancelling its connection was "usually" enough for the server to realise it had gone away, however, adding this extra "final message" has meant that the server-side clean up is now always immediate and much more robust. Nice.