Re: NEW: 3CXPhone ver 1.1.2 for iPhone available
OK, shortly, this seems to be the end of 1.1.2 saga. We figure out the problem is the built-in tunnel, so we stripped it and released 1.1.4, which is now available on AppStore. I will close this thread and I will open a new one for 1.1.4. Apologies from 3CX for two weeks of troubles.
--------------------------------------------------------------
P.S the long story, for who's interested:
As I said, since the first report of 1.1.2 crash, we assumed that, before placing it in the App Store, App Store team did not properly code-resigned (with App Store certificate) our application already tested and approved by Apple Review team. Until now, we did not get any explanation from Apple regarding this. For almost two weeks, we sent them informations, project settings, test cases, all we assumed could be useful to find a solution, but until two days ago, we didn't get any TECHNICAL feedback from Apple, except generic "thank you, we will check, asap, please provide the crash log". Now is coming the interesting part:
On Thursday, we sent them the proof : "we found that in 1.1.2 available on App Store, only the application has been signed by Apple, while the two dynamic libraries not, leading to the known crash. You can see this in the following way [...] attached are [...]". Suddenly, we got the first concrete answer, something like "What? You're using dynamic libraries? You're not allowed do this, it violates the 2.8 rule, Apps that install or launch other executable code will be rejected. We will check the crash log to see what it means, but you're not allowed to use dynamic libraries".
This was our answer:
- our application, as is, with the two libraries, has been APPROVED. Nobody at Apple Review rejected it for "2.8 Apps that install or launch other executable code will be rejected". Nobody. We even don't knew about this requirement. Moreover, in two weeks of ping-pong mails, nobody at Apple Review found that the package contains two prohibited libraries. Two weeks. Even more, trying to clarify the issue, WE told that inside the package are two libraries. If our application would have been rejected two weeks ago with the precise "2.8" reason, not only we would have been able to find a fix, but we would avoid alot, thousands of customers become angry about the crash. They could live with a product delay, could live with a product having a feature less, but not with a product crashing instantly. It was a very sour-taste, very embarassing and sad experience, which could have been avoided by a simple thing: an app rejection with "2.8" reason. But no, it was approved and got the blessing.
- XCode has a validation tool, checking if the app complies with App Store - why it doesn't check for existence of such libraries, or code-signing issues? These checkings are perfectly suitable for an automated tool like this one, saving a lot of time for both developers and Apple Review testers.
So, bottom-line, yesterday we decided to strip the two libraries (basically the tunnel) and to release 1.1.4, ie 1.1.2 with one feature less. Next we will have to find a workaround for the tunnel.