Post not yet marked as solved
I'm on XCode 15.2, and it's also hanging while attaching the debugger.
It seems to happen sometimes (not all the time) when I switch between a wireless connection and a wired connection between XCode and my device. Probably when I lose my patience and plug in the cable while XCode is building/installing to the device.
The above steps alone did not work for me. I found that I also needed to shut down and restart my iPhone. So, here's what I do when this happens:
Close Xcode
Delete ˜/Library/Developer/Xcode/Derived Data
Delete ˜/Library/Developer/Xcode/iOS Device Support (note that I'm not deleting entire Xcode directory as that also deletes your archives)
Shut down Mac
Shut down iPhone
Restart iPhone
Restart Mac
Some of these steps are probably unnecessary, but as this doesn't happen too frequently for me, I just follow this to be on the "safe" side.
Post not yet marked as solved
Same here. Did you ever find a solution?
Post not yet marked as solved
Same here. Also able to reproduce with address sanitizer enabled.
@And0Austria, I can't see your bug report in Feedback Assistant (can only see my own entries). I know it's a long shot, but did you get any response from Apple on your bug report? Or did you find a workaround to prevent the crash?
Post not yet marked as solved
I had a UITableViewController that had some cells registered in the Storyboard. These cells did not cause any problems. But it also contained other cells that I designed with a separate UINib, so I had to register them specifically in viewDidLoad, like so:
override func viewDidLoad() {
super.viewDidLoad()
tableView.register(UINib(nibName: "SCSocialCell", bundle: nil), forCellReuseIdentifier: "SCSocialCell")
...
}
The problem appears to be that these manually registered cells are not really registered before the table starts to load data (which happens automatically in a UITableViewController). In other words numberOfSections and numberOfRowsInSection are called even before viewDidLoad is called (or finished, not sure).
I solved it by introducing a bool variable allTableViewCellsRegistered, like so:
private var allTableViewCellsRegistered = false
override func viewDidLoad() {
super.viewDidLoad()
tableView.register(UINib(nibName: "SCSocialCell", bundle: nil), forCellReuseIdentifier: "SCSocialCell")
...
allTableViewCellsRegistered = true
tableView.reloadData()
}
And adding guard statements in numberOfSections and numberOfRowsInSection like so:
override func numberOfSections(in tableView: UITableView) -> Int {
guard allTableViewCellsRegistered else {
return 0
}
// rest of code
}
override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
guard allTableViewCellsRegistered else {
return 0
}
// rest of code
}
Perhaps only adding this in numberOfSections would do, but I added it in both and it's working now.
I believe this problem only surfaced on the iPad, because the cells in question were at the bottom of my tableView. On iPhone, these last/bottom cells dropped off the screen, so cellForRowAt was not yet called for them on initial load. But by the time the user started scrolling to the bottom, viewDidLoad was finished and the cells were registered. So that's why iPhone didn't give me any problems.
Hope this helps someone.
Post not yet marked as solved
Same here as well. Here's a full description that I've been using for appeal and apple support
App just got rejected for the 3rd time.
The situation is as follows:
The build that's currently for sale in the App Store is tracking user data
The new build (the one that got rejected) is not tracking user data
Review team rejects my app because App Privacy settings in AppStoreConnect indicate that the app is tracking user data (which is correct for the current ‘for sale’ binary), while my new binary is not asking user for tracking permission (through App Tracking Transparency library).
One, by review team suggested way to resolve this, is to adjust App Privacy settings in AppStoreConnect to not track user data anymore.
HOWEVER, when I try to follow that suggestion, AppStoreConnect will not let me make that adjustment, because ‘the binary’ suggest that I AM tracking.
So:
Review team says that my BINARY IS NOT TRACKING user data while it should according to App Privacy settings.
AppStoreConnect says that my BINARY IS TRACKING user data and won’t let me change App Privacy settings because of that.
Chicken and egg situation!
Here's a screen capture video that shows everything: (can't include here, but you get the contents)
I believe one of two things could be wrong here:
My new binary DOES include the the NSUserTrackingUsageDescription somehow
AppStoreConnect is looking at the binary that’s currently for sale in App Store, while review team is looking at the binary in review.
I’m almost certain it’s not number 1. I’m a fairly experienced developer and would know if that description would be in my app. Just to be sure I’ve entered a ticket to Code Level Support to make sure of that. No response on that yet.
More likely it’s reason number 2: a procedural issue in the review team where they are comparing ‘old, soon to be incorrect’ App Store privacy settings with the ‘new’ ‘in review’ binary.
I also submitted feedback through the new Feedback Assistant: https://feedbackassistant.apple.com/feedback/9725783
Post not yet marked as solved
Found this github repo. It creates and MD5 hash without using CC_MD5, thus no compiler warning about deprecation.
https://github.com/onmyway133/SwiftHash
