Evening all. Carried out some updates on an app first submitted (successfully) around a year ago. There is zero difference to the app that I’m submitting today to the one last year other than: Local HTML Files have changed content, but not name. Remote HTML Files have changed content and name but links have been updated accordingly. Built and tested across simulators and range of devices; All working fine. Target deployment is 7.0 +. Successfully submitted but rejected due to the app being unable to launch on the tester’s side. As I say, all launching fine this side (through remote IPA testing, too). I made the necessary changes to the architectures and plist (that need to be done given the code is a year old) but nothing else has changed. I think there are two options (from scouring SO): 1. Set deployment level to 8.0+ (seems silly but has worked for some others). 2. Line by line code comparison with a recent (successfully submitted) build. Before dancing on these, has anyone else come across the same? Crash logs (provided by Review Team) can be seen below: https://www.dropbox.com/s/02ztxeoexfaoc1y/temp..fbmhyaek.txt?dl=0 https://www.dropbox.com/s/45j8ka9a2gmnkk0/temp..ylvixtpi.txt?dl=0 Thanks in advance for any pointers.

If it was me, I would look to see what the differencs are between what you did and what the reviewer did, as clearly it worked for you but not for them. I would also ask the reviewer the spec of his test device. Another thing, perhaps see if your app starts OK without internet access (just a hunch). Btw, I always set my deployment targets as low as possible. I usually go for 6.0 for maximum compatibility acorss older devices and I don't have any problems. Also , I looked at your logs, but they made no sense to me, sorry. Alan

Sadly, I can make no sense of the logs either. If it comes down to 'line by line comparison', I suggest you nab a copy of the free utility 'Diff Merge', an invaluable utility for exactly that kind of thing. I use it fairly often when comparing 'versions'. https://sourcegear.com/diffmerge/ Cheers! -- Smug

Are you using http or https for your remote pages? There was a sly little change in iOS9 that requires all remote webpage requests to be https unless explicitly declared otherwise in the BT_info.plist file. It's possible the reviewer is using iOS9 to do their testing.

If Chris1 is right (and he usually is) then you might want to take notice of this post: http://www.buzztouch.com/forum/thread.php?fid=56E6F34FD963C9510A3C2E1&tid=56E6F34FD963C9510A3C2E1 Cheers! -- Smug

The collected ramblings of a mad man trying to find the root of the problem…. So I’ve backtracked and compared all of the old code (from the app which was rejected) against both a recently successfully published app and a freshly downloaded bunch of source code (from my self hosted server). Thanks to SmugWimp for the diffmerge link, very useful! I had Pare installed in the previous version and to avoid any external issues there have deleted and unreferenced (as third party SDKs can always kick up a fuss). As Chris1 suggested, I’ve added the URLs into the plist file following the introduction of App Transport Security (Good explanation of ATS here: http://ste.vn/2015/06/10/configuring-app-transport-security-ios-9-osx-10-11/). I’ve added my self hosted URL as well as the URL of external webpages I’m calling into the app. As it stands, the app runs fine on anything below iOS9 (across all simulators and devices). The issue comes with running on iOS9 - I can load and run the app on the simulator only on a fresh install; If I then stop the run and try to launch the app from the simulator manually the app freezes on the launch image. (Interestingly, the loading spinner doesn’t even appear). At least I know how the review team were playing with the app! This confirms the error report of “failing to screen create”. With the loading spinner not appearing (and causing the non-screen-create fun!) and it being exclusively an issue on iOS9, I think the AST must be the cause of my woes. EDIT: Looking at the logs during loads, however, it turns out that the custom fonts I was using in the app were causing the issue - my oh my. Deleted the font reference from the plist and problem solved (very annoying though). As an aside, in declaring the expected URLs in the plist, there is an option for allowing arbitrary loads. Setting this to “no” does not allows the styling to come through from external URLs (it seems). Setting it to yes, does allow the styling.

I saw that styling note on the other post. Good information; thanks! Cheers! -- Smug