
Apple keeps rejecting my binary - strzalek
https://medium.com/@krzyzanowskim/im-not-panic-inc-apple-just-keep-reject-my-binary-9aec9af449f8
======
chton
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...](https://developer.apple.com/library/mac/documentation/General/Conceptual/iCloudDesignGuide/Chapters/iCloudFundametals.html)),
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.

------
Mithaldu
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.

~~~
electrum
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.

~~~
daniel02216
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.

------
mynegation
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.

------
krzyzanowskim
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 ;)

------
kenrikm
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.

------
GFK_of_xmaspast
"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.

------
MrDosu
Works on my machine!

