I am working on a iPhone app where I need to initialize large arrays. I use NSMUtuableArrays and all works fine when compiling normally. However, it takes forever to compile to iPhone compared to simulator. There is one particular file which has about 50-60k line.
Anyway, I also need to profile the memory and I always used Instruments in Xcode doing:
"Product" ->"build for profiling"
While I cannot get it to run on the iPhone at all, starting Instruments with this app even on the simulator in most cases it just hangs - even overnight.
Is there a better way to use Instruments or to handle such large source code files?
Many thanks
Related
I'm creating an apple watch app. I have created my shared framework, and the app extension. It all actually works pretty well, but when I try to query objects from my Core Data DB, i get only empty arrays.
I have already created the app groups, and made sure the DB is being saved. I just don't get any objects, or errors. However, i'm not even sure if this is testable in the simulator, since the phone AND the watch simulator don't run at the same time. I still don't have a physical watch to test so simulator is my only option.
How can I test querying CD objects from my apple watch extension? Thanks!
Here is a trick for testing both the watch and the phone on the simulator. As you pointed out, they cannot be debugged at the same time, but you can switch.
Run the phone target, then run the watch app (the phone target will terminate). Now start the phone target manually from the simulator's springboard. You are now looking at the debugging information of the watch.
To switch back and forth between the two running targets' debug output, go to Xcode and choose the desired process from the menu:
Debug > Attach to Process > (wait a second or so for the processes to populate) > Your target (which should be listed on top under the heading "Likely Targets").
I have ported a library (ice , NAT traversal ) for iPhone and encountering issue while actually testing it on iphone device(Version 4.3). Developed a cocoa touch wrapper which is linked with my library. The library routines get called from "test" button placed in my application.
The application is .mm and library is C++ based.
Below are the cases in which my application fails/passes
Case I: I "build and debug" / "build and run" application from Xcode for iphone. The application works fine on iphone and I am able to see logs for the same on the console on my mac machine.
Case II: I try to run application from my iphone, but it just crashes while opening.
Case III: I build and debug application from Xcode, the application get's launched. But as soon as i unplug the debug cable (attached to iphone from my mac), the application get's crashed.
The size of application is 16 MB, and size of library is 288 MB.
I tried to simulate same issue by making a simple test application and a test library. it runs fine in all cases without issues. What can be the issue?
It seems that the application is mapping library code from mac machine while running on iphone. and once the physical link is broken, the app crashes.
size of library is huge?
Thanks in advance
iOS kills apps that blocks the main thread for too long. So that may be the problem and also explains why the app doesn't get killed in debug mode.
Try running your function in the background and see if that helps!
Finally I got answer to my question! Thanks a lot Martin for pointing out "iOS kills apps that blocks the main thread for too long"
Following is the procedure i followed to find the resolve the issue:
Xcode "orgainzer"--> "Device logs" section shows iphone crash report. My application crash report was also generated in the same.
In crash report it was clearly written "mytestapp failed to launch in time" and further it showed the API which was taking too long to return the result. ( in my case it was getlocalhostname API).
I just corrected the API as per my requirement, compiled and run the app on iphone device and it worked!! Also the launch time of application is pretty less now.
Thanks again!
I was wondering if is there any way to quickly check iOS/objective-c snippets or new code inside my xcode project without having to compile the whole app for that, open up the simulator just to get the NSLog message traced on the console.
I remember when life was easier using ruby's irb or node command for node.js :)
It just gives me the impression that on iOS development you have to learn how to deal with this high complexity and dependencies all the time, but I am just starting on this new world. so any help would be appreciated.
thanks a lot
This timely blog post should help; I'm using it often already.
Update: there is also Code Runner available in Mac App Store - this supports many languages, including Objective-C.
An Xcode project can contain multiple targets. One of the targets can be a test driver in which you can put some class/object/snippet exercise code and drive it from the command-line, results to the debug console. Another option is to create unit test targets.
If the code you're writing has known expected input-output pairs and you're just writing code to make them work, you may want to look into using XCode's unit testing capabilities. A link to a tutorial on using unit tests is at http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/UnitTesting/0-Introduction/introduction.html . If you want to test more interactive things, it is possible to use Instruments (a program in XCode) to automate those tests as well using the Automation instrument. A guide on using Instruments is available at http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/AboutTracing/AboutTracing.html .
Not really—Objective-C is a compiled language, while I believe Ruby is interpreted (which allows for interactive testing like what you describe). You can reduce some of the overhead of building and running your project by just leaving the simulator open; stopping the app from Xcode will close the app but leave the simulator running, meaning that a rebuilt version of the app will launch more quickly when you run it.
A project i'm working on is crashing when built with release configuration.
We need to send the application to apple for review and it is crashing before even entering the app.
Any idea how that could happen?
In last ressort, is it possible to send to apple a debug version of the app with some optimizations?
thanks.
The same thing happened to me when building my first iPhone app - after working on the project for a while when switching from debug to release the app would crash. I did a full clean rebuild of the project, deleted the app from the test phone and reinstalled it, and the app ran. It looked like XCode sometimes does not clean up/rebuild everything it needs to.
In my experience, 9 times out of 10 annoying, hard to track down crashes in a non-debug vs. debug build of anything, iPhone or otherwise, is caused by a memory management bug. I'd put money on your issue being caused by an improperly placed release or retain message, or lack thereof. If you haven't tried it yet, turn on the static analyzer in your debug build configuration (my XCode is updating right now, but I believe if you search for "analyzer" or "clang" in your build properties you should find the appropriate setting) and see if it points to anything telling. If it doesn't, you can use Instruments to help you check for problems, as well as attempting to isolate the problem area in the debugger.
It might help you to reproduce the problem in a not-actually-a-release-build by modifying your debug configuration or duplicating it to use a different set of compiler flags that more closely aligns with what happens in the release build (I don't recall what the differences are off the top of my head, but I would assume adding a "-O2" to your compiler flags would get you most of the way there).
If you build with Release configuration, make sure you keep a copy of the .dSYM file and the application bundle.
Then when the application crashes on the device, plug it into Xcode and download the crash reports.
Open Xcode and then open the Organizer from within Xcode. From there you can view crash reports from a device.
The crash reports will be symbolicated if (and only if) you saved the .dSYM file and the application bundle.
You can then use the crash reports to find out why it is crashing, and fix it.
You should look at your Crash Logs. Open Organizer, select your device, then the "Crash Log" tab. Scroll down to find your app's logs. The should be symbolicated, so you can see the stack trace.
Without actually debugging your app, it's really hard to say more. Are you using an #ifdef DEBUG macros? Are you using more than one thread? If you have a bunch of NSLog statements that slow down execution in debug mode, this can introduce subtle timing differences that can impact multi-threaded apps.
Did you try a 'make clean' on your debug version? Sometimes obscure bugs can be hidden when parts of your project are rebuilt while other parts are unchanged.
Curious what practices people have learned before making their final build and submitting to the App Store? Aside from switching from Debug to Release & commenting out calls to NSLog what other basic and/or not so basic things should we be watching out for?
This is a good question and I'd like to restate some of the answers and add a few of my own. I've made this answer Community Wiki, feel free to add to it.
Delete the app from your device, turn off WiFi, off cellular data, now install and test app. Does it work properly (as much as it can without Internet)? Does it at least tell the user that a network connection is required (if it is) or does it crash?
If you use CLLocationManager: Delete the app, fresh install and run, but do not allow app to have Location Data. Does the app behave well or does it crash? Does it at least tell the user that it can't run without location data (if that is a requirement)? Does it work on an iPod Touch that does all geo location using WiFi only?
Run the app in the simulator and for each view controller do the following steps: (a) From the iPhone Simulator menu select "Hardware" --> "Simulate Memory Warning", (b) now navigate around your app to other view controllers and see if everything is working, (c) repeat test for another view controller.
If you support older firmware (ie: iOS 3.1.3), install your app on a device running 3.1.3 and test it there (if you don't have one, use the 3.2 simulator).
Start your app while on a phone call or when Personal Hotspot is active. Are all the screen layouts correct (the status bar is 40px high instead of 20)? Did the bottom 20px of the view get pushed off the screen or did it resize correctly?
Accept a phone call while in your app, does it resign active and resume properly? Do sounds from your app stop playing while in the phone call?
Start your app while playing music, does the music continue to play? Do your sounds mix properly or fade the music appropriately?
Test performance on a slower devices with limited RAM such as: iPhone 3G (128MB RAM, 412Mhz CPU) or iPod Touch (1st or 2nd gen).
Run the Clang static analyzer and fix (or at least understand) every warning.
Make sure NSZombiesEnabled is NO in the environment variables (caution: not sure if this is still a problem)
A few things:
I actually recommend not creating a build configuration called "Distribution" as Apple specifies, because I often am creating ad hoc builds for beta testers. I create two build configurations, one called Ad Hoc and one called AppStore, so I'm not confused. The only difference between the two is the presence of the Entitlements.plist file for the Ad Hoc build. This way I can test as closely as possible what I will be submitting to Apple.
Most developers are optimists. That's why we are working weekends to create an app that we just know is going to make us a millionaire. Before submitting though, be a pessimist. Imagine everything that can possibly go wrong, and double check it.
Don't assume anything. Don't assume that that tiny little change you made to the app won't affect anything else. Murphy's Law says that that tiny change will cause your app to crash on all iPod Touches or something. Test, test, test thoroughly between the final code edit and Appstore submission. If you have to make a tiny change, then repeat until it's perfect.
Remember that if the app doesn't crash for 99.9% of your users, then 1 out of every 1,000 downloads will result in a 1-star scathing review.
I use Clang static analyzer, Leaks and Object Allocations during development, but I do an extra run of these tools before submission just in case.
If you don't have an older device, get one, because the 3GS performance is significantly better and you may miss some important performance issues.
Test your app with the following configurations when network or location are applicable:
iPod Touch
iPhone 3G
iPhone 3GS
iPhone in Airplane mode
iPhone with Wi-Fi
iPhone with EDGE
Call the phone while using your app
Instead of switching to Release, I switch to "Distribution". It's a copy of Release, but that's is how I got taught by some Apple doc and iPhoneDeveloperTips.
Important points:
After the final build, but before you rush off to zip up your app, open the bundle using the Finder's Show Package Contents. Due to some bug in the MacOS, which bit me in versions prior to Snow Leopard (and it might still be there), if you zip up too fast (using the Finder's Compress or Archive menu item), some of the resources have yet to be flushed out into the file. When you do a Show Package Contents, the contents get updated. The way you would notice this problem is that the size of your compressed app would be between a fifth to a tenth or less of the expected size. You might think to yourself, "hey, that zip utility really does a great job of compressing", but that's not the case. This problem would occur at this point instead of during testing mainly because you are doing a "clean all" build and all the resources and contents of the app bundle are starting out empty and then being filled by Xcode. And for some reason, even after Xcode is done creating the file, the contents are still not actually there, if you compress, but would be there if you looked at them (sort of a reverse Heisenberg). Beware.
Another area I spend a lot of time on is to make a nice backup of the sources, after I have committed all the latest changes to SVN, made a new branch, and tagged the file. I also like to have my version number match my SVN build/commit number so I always know which SVN version matches my release. I have those two version numbers in my info.plist and can be pulled up by the app user when they hit i for info. For example, a current info.pist includes:
<key>CFBundleShortVersionString</key>
<string>2.0a1</string>
<key>CFBundleVersion</key>
<string>346</string>
There are different thoughts on how to use the CFBundleVersion. This is my way. Also useful is the command line utility, agvtool.
Once the app is built, after compressing so you're not actually making any changes to the compressed version, go check the app file and make sure it is signed with the right distribution cert and not your adhoc one. Learning to use the command line utility, codesign, is helpful for this kind of checking and debugging. By making the compressed copy first, you ensure that you're not in any way going to change the final copy that Xcode has handed you and that you will upload to itunesconnect, if all looks well.
Other things to remember are the app icon, the various other icons and graphics you need for the iTunes store, the info.plist, and the fact that when the uploading of the app fails with a cryptic error message, it usually has to do with one of these pieces being missing from the compressed file you are building (those pieces that belong in the app bundle).
Look into this check list document # Github
https://github.com/bapu/AppReleaseCheckList