Post not yet marked as solved
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.)
Post not yet marked as solved
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."
Post not yet marked as solved
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."
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
I haven't personally encountered the issue, but the key was deprecated and according to google, you need to just remove the key. If you're editing the plist in Xcode (as opposed to a text editor), the name is apparently shown as "Application does not run in background"
Post not yet marked as solved
I just got one of these and started working with it. It seems to take a little time for the controller to appear and if the first call to [GCController controllers] is near the beginning of app launch, you might get an empty list. Register for the connect/disconnect notifications and the program will be informed shortly when the controller shows up.
Post not yet marked as solved
The message tells you what's required: "This app was built with the iOS 11.4 SDK. ... [A]ll iOS apps submitted to the App Store must be built with the iOS 12.1 SDK or later, included in Xcode 10.1 or later."
https://developer.apple.com/app-store/search/"Keywords are limited to 100 characters, so it’s important to be concise when describing your app. While spaces should not be used before or after the commas that separate keywords and keyword phrases, you can use spaces to separate words within keyword phrases. For example: Property,Real Estate,House."
Post not yet marked as solved
Same deal here. I never received any feedback email, and there are a few screenshots and comments on App Store Connect, but the All Testers section shows someone with 200+ feedbacks.
Post not yet marked as solved
And you're getting no "SKPhysicsContact detected" messages? I'm afraid I'm about at the limit of being able to remotely debug. I'd suggest just making a simple test scene, two squares, set the physics bodies and category/contact bitmasks, and do the rotation. I do this and do get contact messages:class GameScene: SKScene, SKPhysicsContactDelegate {
let squareSize = CGSize(width: 100, height: 100)
func makeSquare(color: UIColor, category: UInt32) -> SKSpriteNode {
let square = SKSpriteNode(color: color, size: squareSize)
let body = SKPhysicsBody(rectangleOf: squareSize)
square.physicsBody = body
square.zPosition = 1
body.categoryBitMask = category
body.contactTestBitMask = category ^ 0b11
addChild(square)
return square
}
func didBegin(_ contact: SKPhysicsContact) {
guard let node1 = contact.bodyA.node else { return }
guard let node2 = contact.bodyB.node else { return }
print("contact \(node1.name!) and \(node2.name!)")
}
func rotate(_ sprite: SKSpriteNode) {
sprite.run(.rotate(byAngle: .pi, duration: 1))
}
override func didMove(to view: SKView) {
let square1 = makeSquare(color: .red, category: 0b01)
square1.position = .zero
square1.name = "square1"
let square2 = makeSquare(color: .blue, category: 0b10)
square2.position = CGPoint(x: square1.position.x + 1.05 * squareSize.width, y: square1.position.y)
square2.name = "square2"
run(.wait(forDuration: 3)) { self.rotate(square1) }
}
override func update(_ currentTime: TimeInterval) {
// Called before each frame is rendered
}
override init(size: CGSize) {
super.init(size: size)
physicsWorld.gravity = .zero
physicsWorld.contactDelegate = self
anchorPoint = CGPoint(x: 0.5, y: 0.5)
}
required init(coder aDecoder: NSCoder) {
fatalError()
}
}I also checked that at least one (but not both) bodies must have isDynamic true. One thing I hadn't thought about is that the squares will push each other during the rotation, which is kind of suggesting that you may not want the physics engine involved at all. That is, I'd probably use just a discrete grid representation and have a rotating square check the neighboring cells for their status in order to capture them.
