Post

Replies

Boosts

Views

Activity

Reply to App is getting rejected due to 'Guideline 2.1 - Performance - App Completeness'
It's your app, how are we supposed to know? We're just developers like you. The App Review Team will have taken the credentials you gave them, and tried to login. When the login failed, they stopped reviewing it and informed you of the issue. That'll be the extent of their information on how to reproduce the issue. Do you have any logging on your server so you know why the login failed? Have you tried to debug it, and follow through the code to see what happens when you attempt to login with those credentials? Whilst stepping through the code you might notice something that could be causing the issue. Why is the password field blank? Does it get wiped the moment the user presses the Login button? Did the App Review Team attempt to login without a password? Did you give them a password? So many questions...
Jul ’25
Reply to Behavior of Image and ignoresSafeArea
When you do this: Image(.background) .resizable() .scaledToFill() .ignoresSafeArea() You're telling SwiftUI that the image can be resized, and you want to scale it to fill its parent, so SwiftUI scales the image. However, at this point, SwiftUI doesn't know that the image can ignore the safe areas, so the parent view at that point isn't ignoring safe areas. That's why you get the white bit at the bottom. I took your image and added a red border and yellow squares in the corners so I could see where the image was stretched/resized and positioned. With the code above, you get this: So you can see it was resized to fit inside the parent view, and doesn't ignore the safe areas. For your needs, just remove the .scaledToFill() modifier, you don't need it: Image(.background) .resizable() .ignoresSafeArea() This yields: If your ultimate need is to get that last image with just the white bit at the bottom, the fix again is to remove the scaling: Image(.background) .resizable() .ignoresSafeArea(edges: .top)
Topic: UI Frameworks SubTopic: SwiftUI
Jul ’25
Reply to Avoiding a macOS Tahoe window corner in objective-c
I can't help you specifically with this, sorry. I know it's a pain to migrate from ObjC to Swift/SwiftUI - I've been there - but there are two options: Migrate from ObjC one file at a time; Rewrite the app from scratch. I completely rewrote one of my ObjC apps within a couple of weeks in my spare time, and it has far less code in it. Things like filter, map and compactMap reduced my code so much. You could do this as a separate project while trying to update the original app. So, make the necessary updates to the original and also start writing the new version from scratch. You'll probably enjoy it. And if you need any help at all, just ask.
Topic: UI Frameworks SubTopic: AppKit
Jul ’25
Reply to App rejection
Why post this twice? It just clutters the forums. Anyway, as answered in the other post - have you tried it on an iPhone 13 mini like the App Review Team said? If it is working on my iPhone 11, iPhone 16 and iPhone 15 then it should work in every iPhone. Nope, that's not how it works. There are differences in screen size and resolution that you may not have considered. The fact that the App Review Team tried your app on an iPhone 13 mini and it did not work should prove to you that your statement is wrong. Just test it on an iPhone 13 mini Simulator.
Jun ’25
Reply to App rejection
The App Review Team specifically mentioned iPhone 13 mini with iOS 18.5. Have you tested your app on that device with that version of iOS? See what happens when you run it on the Simulator if you haven't got a physical device to test it on. (Also, don't answer your own question unless you're definitely providing the answer - your response doesn't look like an answer.)
Jun ’25
Reply to Can some of those simulator files be safely deleted ?
My iOS folder is only 9.13GB, and my watchOS folder is about 4.8GB, so Ive no idea how you've got that much data in there! In my Xcode > Settings Components I have iOS 18.5 which is 8.84GB (which is close to 9.13GB), and my watchOS 11.5 is 4.68GB (close to the 4.8GB on disk). My best suggestion is see what simulator runtimes you have in Xcode, delete the old unused ones, and see how much space that saves. It may be that you've somehow got old ones on disk that Xcode doesn't know about (i.e. Xcode only lists iOS 18.5 but your AssetsV2 folder has folders within for 17.5, 16, 15 etc.), so it would be safe to delete the old ones from disk.
Jun ’25
Reply to EXC_BAD_ACCESS When saving core data
Your updateLocal() func has a sort descriptor with two of the same values: fetchRequest.sortDescriptors = [NSSortDescriptor(keyPath: \Project.name, ascending: true), NSSortDescriptor(keyPath: \Project.name, ascending: true)] - does this do anything in particular? Anyway, you're doing an awful lot work in what should be a simple Core Data update function. Have you tried retrieving from Core Data all the projects that need updating, doing your updates to the various bits, and then saving the context in one go?
Jun ’25
Reply to Petition to bring back as an option old multitasking!
They are permanently removed in favour of the new windowing. However, if you want them back I suggest you raise a feedback report requesting their return. It's unlikely to happen, but if enough people call for it, Apple might change their minds and find some way of implementing them again. https://feedbackassistant.apple.com/
Topic: UI Frameworks SubTopic: UIKit
Jun ’25