Make one big image that contains the stay-the-same part plus the border. Create the scene to have the size of the stay-the-same part. Set the scene's scaling mode to aspectFit. Put the background image in the center of the screen. Different parts of the image border will get cut off for devices with different aspect ratios. (Or maybe aspectFill and set the size appropriately so the smaller dimension matches the desired stay-the-same part.)

From https://developer.apple.com/app-store/app-previews/"You can have up to three app previews for each language your app supports, and each preview can be up to 30 seconds long."

From Apple's documentation on complying with encryption export restrictions:"Typically, the use of encryption that’s built into the operating system—for example, when your app makes HTTPS connections using URLSession—is exempt from export documentation upload requirements, whereas the use of proprietary encryption is not."https://developer.apple.com/documentation/security/complying_with_encryption_export_regulationsYour bigger problem is likely to be 4.2 in the app store review guidelines: "Your app should include features, content, and UI that elevate it beyond a repackaged website."

You haven't provided much to go on, but whatever information you collect has to be needed for some reason. Just disclosing that you're collecting something and linking to the privacy policy in the app doesn't give you a free pass. Since most colleges nowadays are coed, maybe you don't need gender information at all. If your app, e.g., did some sort of profile and then suggested a list of colleges, you could make the list while ignoring gender. When you present the list, you perhaps have little indications already for things like public/private, in-state/out-of-state, 2-year/4-year, etc., and you could just add another indicator for those few colleges that are not coed.

The source of our app is available on GitHub, so you can take a look there. Here's the relevant file:https://github.com/bg2b/RockRats/blob/master/Asteroids/scenes/BasicScene.swiftThere's a discussion of the memory leak issue around line 500 onwards. We ultimately used a kind of pixelated filter for the game's pause effect, but did try a Gaussian blur as well, and that blur shader is still sitting in the code (starting around line 575). It's one pass and not the classic two-pass Gaussian blur since we didn't want to make an intermediate effect node, but you could do that too if you need a large blur.The comments there also mention an alternative approach. You can render the blurred part of the scene into an SKTexture using the view's texture(from:) or texture(from:crop:) methods, then run that texture through a CGImage -> CIFilter -> CGImage -> SKTexture -> SKSpriteNode sequence to get a regular sprite node that shows the desired effect. It's a little slow in general (probably around 1/10 of a second, enough to be noticed when you pressed the pause button in our game). For the blur case, you can avoid that lag by scaling the part to be blurred down, doing the CIFiltering, and then upscaling the result. It's blurry anyway, so you won't notice the difference. We didn't go with that method because we need a different pause effect in certain circumstances where the scaling wasn't feasible.

There appears to be currently (as of iOS 13.x) some memory leak of IOSurface stuff when using an SKEffectNode wth CIFilters. We were using that functionality initially for blurring the playing area when a game was paused. But repeated pausing and unpausing (i.e., toggling shouldEnableEffects) would gradually pump up the number of retained IOSurfaces and memory as much as desired. We switched the code from using a CIFilter to a custom shader on the effect node; that fixed it.

Maybe you can set up a call with app review to discuss the issue. They're the only ones who can really tell you what the issues are and what might satisfy them.

Yes, there are other possible distractions, but that's why there are settings like Do Not Disturb While Driving to explicitly cut off most of those. Voice navigation is one that is generally allowed, but it's also not as unpredictable. The user is often anticipating potential instructions when approaching the area where there are some turns or exits, the apps often set up a context for when the next instruction will be given (e.g., "proceed 25 km" after merging onto a highway), etc.

At an abstract level, any app that is designed to be active while the user is driving is probably going to be subject to very close scrutiny. An app that attempts to alert the user in some manner when it suspects the user is distracted is itself a potential source of distraction, and a false alarm could potentially cause an accident that would not otherwise have occurred.