If I build my iPhone application and Xcode shows compile-time warnings, will it be rejected if I submit it to the App Store?
What types of warnings? Every warning you have can be fixed with proper coding.
I ask because while the warnings themselves may not get your app rejected, but crashing, bad memory management that results in the app eating up lots of memory and not releasing it (resulting in a crash eventually), or the app just not functioning as described will get it rejected.
Do you not want to fix the problems to ensure your app runs well, gets good ratings due to satisfied customers, and therefor sells well?
Apple is not gonna reject the application because of warning. But be sure that you haven't used any Private API. If possible remove the warning. It is not a difficult task for you. If you can develop application than why you can't make it warning free ?
These warnings won't show up when you use the app.
They are just hints of XCode to tell you that they could be problematic.
You only need to be sure that the warnings don't produce a crash. If so Apple will reject your App.
Related
I'm a newbie. I've worked out all the bugs I can find in my app, but before I find beta testers and ultimately submit to the app store, I want to make sure I don't leave out any important steps. For example, I see several questions talking about checking for memory leaks, but I don't really know what that is or how to do it; same thing with the sandbox. I've already created a signing certificate and a provisioning profile and registered my device.
So: assuming that my code is all working, what else should I do or check for?
(If this isn't an appropriate stackoverflow.com question, I apologize; please let me know, and I'll remove it asap.)
Definitely check for leaks.
Leaks are where your app doesn't give up memory to the system after it has finished using it. This can mean (a) Your app uses more memory than it needs to and (2) the device runs out of memory if your app runs for a long time, and your app can crash and other apps will be closed.
Here's a guide to finding leaks, using a tool called Instruments that comes with Xcode.
http://mobileorchard.com/find-iphone-memory-leaks-a-leaks-tool-tutorial/
Also make sure you write 'review notes' for the reviewer if there's any aspect of your app that won't be immediately obvious. If you need a login to use the app, make sure you provide a test one in the review notes. Consider making a (private?) YouTube video showing the app in action.
A user is reporting a crash in my app but I can't seem to recreate it and have not heard of this crash from any other users. He claims the app crashes when he comes back to it after using different apps. There are no crash reports on iTunes connect either and hes using the latest device and os.
Have the user follow the directions here:
http://www.ispeeddial.com/how-to-find-the-crash-log-for-an-iphone-application/
You should not worried about it much. There are many SDk around which allow user to submit there bugs/feedback direct to developer rather than on itune store. There may be several reason either he/she put down your app(marketing strategy). But the nicer solution is i can tell you that somehow may depend of your code may be related the memory leak. If you are confident with your coding standard then finally you should not worry about until unless many people does not complain about it
I was wondering if anyone has any experience with uploading applications.
At the moment we have an application without any leaks, and how hard we even try to create a crash, in both the simulator and the actual device it just wont let us crash it.
Now we're curious if there are any other developers out there that has been in the same situation and sent their applications to the app store and what the actual outcome was. As we're very cautious and dont want to waste our company's resources we'd like to get as much feedback as possible and cover everything before submitting to the app store.
Please feel free to share.
Thanks in advance!
Ensure you don't use any undocumented API's immediate fail.
Follow the Apple criteria and make sure your app fits their restrictions....
Check my post App Store Approval which contains a link to the criteria....
Good work having a thoroughly tested app and I admire your desire to ensure your submission is pain-free. Good luck!
If it does want you want, and you are happy with the amount of testing you've put in it..and it follows Apple's app store guidelines, I'd say its ready for the app store. Quite a large number of apps have huge glaring bugs, so if yours never crashes (doubt this), you are one of the very few.
Also, the process only takes about a week, so I wouldn't say its the end of the world if it somehow gets rejected or you find a bug later.
You can create an ad hoc build and send the application to some iPhone users and ask them for feedback on application. And if app crashes just get the application logs from itunes.
Apart from running a private beta or adding a crash reporter, there isn't much more to do than checking the App Store Review Guidelines and send your first version.
One issue I ran into is that the plural of a word counts as a whole different keyword. Example, looking up snippet won't return applications tagged snippets so be sure to include both of them.
I have an app that I occasionally receive support emails for that say the app crashed on them and won't open up anymore. It shows 'Default.png' then exits. Even when the app is deleted and reinstalled.
-I get no crash reports or memory issues (as reported by itunes connect using reports from a significant sample size >20k downloads)
-I've confirmed it's not limited to a specific model and not caused by jailbroken devices.
-The app doesn't have external dependencies, so why would reinstalling it not fix the problem?
What kind of problems could cause the crashing to go unreported and be persistent?
If you have an uncaught exception handler, depending on what you have in there, you will not get reports written out the same way, or at all, as if you did not have a handler. This will make iTunes think there is not any crash reports at all. Uncaught exception handlers are commonly added as part of analytics frameworks, or third party notification tools.
While this could answer your question, a more reasonable explanation is that the crashing devices just need a device restart.
I think every app developer with a sizable install base has struggled with an issue like this in the past.
Are you using any sort of analytics package, such as Flurry, that helps you report crashes? We used Flurry with much greater success over Apple - Apple won't start reporting crashes to you until you have many -- and "just a few" is never enough.
Additionally, if it shows the default.png and crashes, take a hard look at your start-up code. Are you setting something in NSUserDefaults, that if, corrupted, could cause the app to crash on startup?
Admittedly it is strange that a delete-and-reinstall doesn't do the trick.
The users aren't reporting the error reports to Apple. The crashes could come from any number of sources.
You could walk a user through the process of digging crash reports directly out of iTunes during the next Sync and email them directly to you.
You could try asking a user to delete the app from the device, reboot their device, then have them install the app again after a fresh reboot.
After submitting our application several times, we continue to receive the following response:
Thank you for submitting My App to the
App Store. We've reviewed your
application and determined that we
cannot post this version of your iPad
application to the App Store because
My App is crashing on iPad running
iPhone OS 3.2 and Mac OS X 10.6.2. My
App crashes upon launch.
Unfortunately, crash logs have not
been generated.
However, resigning the same build with the AdHoc entitlements and loading the build onto the device yields no such crash. After a number of attempts, the application simply does not crash as reported by the reviewer. Furthermore, the reviewer does not provide any useful logging that may have been generated by SpringBoard such as an exit status or event if it had worked properly for any other device. There are no calls to explicitly exit or quit the application in the code line and yet the application terminates on startup.
What might cause an application to terminate in such a manner?
Under what conditions is an application tested that might not be found under a development environment?
Could it be a result of a signing issue that the submission validation system is simply unable to catch?
Thanks in advance.
After fighting with this for weeks, the application has finally been approved. The key: signing corruption. Hence why the application would start (or at least appear to start by showing the splash screen) and then suddenly vanish without a crash log. It failed Springboard's preflight sighing check.
A good tool to keep in mind to check for signing issues. It tells if the application has a valid signing:
codesign -vvvv MyApp.app
When I built the application, I would cp it to a network storage device where our product manager would pull it down and submit it to Apple. If decompressed on the NAS, the code signing was valid. But if you coped the compressed application back off the NAS and validate it, it would fail.
The lesson: make use of the new XCode utility to submit applications.
A few suggestions:
Try to use the leaks tool of the static analyzer to see if there are any memory leaks or problems your not seeing.
Does your app use a web service? This happened to me one time because the day Apple was reviewing the app the web service went down. That cause a crash. If thats the case you would want to add something to catch that.
Finally, In the logs Apple sent you did they send you the dsym file? If they did you can run atos from the command line and it will convert the address to symbols. That will show you what thread and symbol it's crashing on.
Be sure you test with a variety of settings: with Wifi disabled/enabled, with 3G disabled, Airplane mode on/off, location services disabled, etc.
As a last resort, assume there is a problem in your code that executes at startup. Remove half your startup code, set your release date in the far future (just in case it gets approved), then resubmit and see if they have the same problem. If not the problem is in the half you removed... it's a binary search.
I think you have two options: try harder to reproduce the defect using the tools other people are mentioning or to catch those crashes in the field.
PLCrashReporter will trap on an uncaught exception and store all relevant information. Next time your app is run, it can send the crash report that you can then symbolificate and view a stack trace of.
Ouch! That's a tough one. I've had this kind of thing happen before, but it seemed it was reproduce-able when I switched to a different device (iPhone 3G vs 3Gs, etc.). In your case though, it sounds like you're iPad only, so that might not help. There's a difference between 3G and Wifi, I suppose, but I would be really surprised if that was causing a crash on one and not the other.
One thing you could try if you think Apple's not doing their part is to change the binary name and re-submit it under another app name/record. See if you get the same response. If you get the same reviewer, you might, but I think there's a good chance you would get a different reviewer with a new app. Just set your app release date to some time in the distant future and it will never actually show up in the app store if they approve it. If the new app comes back rejected for the same reason, you've got work to do, but if they do in fact approve it, then I would get on the phone with them and point out the discrepancy.
My approach would be to make sure that the compilation is absolutely clean both in the static analyzer (this is NOT optional, it will save you time!) and for the build itself. Then set everything as described on CocoaDev' NSZombie page. Then make sure you have an iPod running 3.2 (actual hardware, not simulator) and test, test, test. Do it with network available and not available, with the device nearly full and freshly restored, every other variation you can think of. Run it with the debugger active and as a release build disconnected. Use Leaks, Instruments and all the other tools to peek in there and get a better feel for what is happening. If you exhaust every possibility you are going to have to beg for more detail from Apple but I bet you find a problem - one of the most important things in debugging an issue like this is to try to forget everything you think you know for sure and start at the beginning.