This happens most likely because the initiation of your scene file has a specific scale mode (see here) along with the sizing fit for the pre-X iPhone screen. So let's say your scene file frame is 640 x 1136 pixels, which is the base resolution of early post-4s iPhones (at 2x pixel depth). At the same time, your scene's scale mode might be for example SKSceneScaleMode.fill. This would stretch the whole screen in height on an iPhone X, because it's comparative screen size is around 640 x 1386 pixels.
Scale modes (see here):
.fill - Stretches both x and y axis from your scene file frame to the final screen size. The most potential of unintended stretching, so you really need to know what you're doing when using this.
.aspectFill - Both x and y are scaled with the same factor, which is determined by the larger one. So basically in this case things aren't stretched out of shape at all and you won't see any unused black areas, but you're likely going to see some of your frame be cut off screen.
.aspectFit - This is exactly the same as .aspectFill, except the scale factor is determined by the smaller one. This means that you'll always see everything on screen and nothing will be stretched out of shape, but you'll see black letterboxes on non-fitting screens.
.resizeFill - The scene is not scaled at all, but resized based on the dimensions. This to me is the most confusing one.
So, anyhow, for you to support multiple aspect ratios and devices, there are really only two options if you don't want stretching, things cutting off or potential black letterbox bars. The first one is to have one scene file where you have your stuff, then you move those things around in code to best fit each screen size universally. It's basically what you had to do in UIKit before Auto Layout came out. Alas, there is no Auto Layout for SpriteKit, so you have to be a bit more clever.
The second option is as laborous, or perhaps more, where you have multiple scene files for each aspect ratio. This is a bit of a control freak approach and is really only apt if you're trying to avoid coding by building things mostly visually. Plus, you'll have to personally identify the device's aspect ratio with custom code. I personally use this approach, because it allows me full control of what things look like on each aspect ratio type. Since the iPhone X brought in this crazy tall size, it's more often than not that I have to design a different layout for it, as opposed to an iPad.
Not to get too deep into this rabbit hole, but I'll add this just for common knowledge. iOS devices only use four aspect ratios, if we think of post-iOS 9 (we drop out the original iPhone ratio, which died with iPhone 4s). There is the normal iPhone ratio, 71 : 40 (1136 x 640 px), which was established with iPhone 5, went on until iPhone 8 and is still used in iPhone SE. Then there's the new (weird) iPhone ratio, 2436 : 1125 (2436 x 1125 px), which came in with iPhone X and will most likely be the standard going forward. On the iPad side, you have the normal iPad ratio, 4 : 3 (2048 x 1536 px), which is used by all iPads, except one. That one annoying outlier iPad marks the fourth ratio, 275 : 192 (2200 x 1536 px), which exists only on the 2018 iPad Pro 11". So for me personally, I have four scene files, which allows me to directly target each aspect ratio separately, which in some cases has allowed me to make radically different layouts for each one.
Anyway, I would recommend you look into all this and figure out how universal you wish to be with your one codebase. If you're doing something pretty simple and just want to have buttons hover a certain distance from the edges of the screen, regardless of what device it is, go with option 1. If you're nuts like me, go with option 2 . But before anything, experiment with scene scaling modes.