Apple keeps rejecting my binary | Hacker News Reader

Apple keeps rejecting my binary

medium.com

38 pointsstrzalek10 comments

I'm not an iOS developer, so take what I say with a grain of salt:

- The first call mentioned seems to request a URL for iCloud. According to official guidance (https://developer.apple.com/library/mac/documentation/Genera...), you shouldn't call it from a main thread. Is it possible that the poster is doing that? The trace he gave indicates it went wrong during a wait, so that would be the first avenue for searching.

TestFlight may be testing an edge case, but experience learns that if their configuration allows them to do something that crashes your app, you'll have problems like that in the wild too.

- In the second problem, the submission to the appstore, the note from the reviewer clearly indicated that it did launch, but it did not run at the correct resolution. It's supposed to maintain the resolution it would have on an iPhone, not scale up or down by itself. Forgive my bluntness, but this problem seems to be one of language barrier, not of Apple's testing systems.

The post writer comparing his problems to Panic Inc.'s seems a bit much. Panic had a genuine problems with the rules, not a technical one. For them, the process didn't go wrong, the rules it followed simply weren't up to snuff.

This seems to be a case of Apple doing the right thing in a weird way. The docs say not to call this function from the main thread, but from a background thread:

    https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSFileManager_Class/index.html#//apple_ref/occ/instm/NSFileManager/URLForUbiquityContainerIdentifier:

(Url quoted because the : is part of it and hn-auto-linking won't include it.)

From that first screenshot however he is calling it from the main thread, and their test system likely is built to trap that with a crash.

It also may be because it returns nil if the user hasn't set up iCloud and the app may not have handled that case properly.

The screenshot shows it crashing on a method named "semaphore_wait_trap", so that does indeed seem to be an intentional trap for calls that can block the main thread.

That's just the syscall for waiting for a semaphore to be signaled. Most likely the crash is due to the main thread waiting for too long on that semaphore - it's likely stuck waiting for a network request to complete, and the watchdog kicked in and killed it.

Title is a bit confusing. At first, I thought that their app is rejected because Apple thinks that it is somehow tied to Panic Inc and this is bad. Apparently there was some previous misunderstanding between Apple and Panic and Apple rectified things and apologized. Author claims that unlike Panic Inc., they do not have influence and brand recognition for that to happen.

Hi, somebody put this link here. Thank you for you comments about main-thread issue, surely it may be the reason behind crash (I would expect warning or exception but hey, I've should read documentation more carefully).

This is a great community, I love you all ;)

iOS Developer here. This is pretty standard, I've been rejected for having a UIWebView (not even a main feature) in an iPhone App that displayed content that did autoscale correctly on the iPhone but when the user agent changed to iPad (still an iPhone app) it would resize the page to the iPad dimensions. I don't know how Apple can expect you to have control over content on the web but in some cases they do. So yeah expect to see "Rejected" a decent amount and this is indeed Par for the course. Best bet is to just fix it, suck it up and resubmit.

"And I’m pretty sure it’s something wrog with their testing environment, because this call shouldn’t crash and it’s not with properly configured system"

I don't do iOS, but I hate programmers like this.

Works on my machine!

Reply on news.ycombinator.com