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").
Related
I am trying to figure out what the differences is testing on different layers in regards to accessing the main bundle, documents directory etc.
I know that when testing on the simulator it creates a copy of the execution environment which is separate from xcode. What about on the device and on app store and what is the difference?
The simulator is there as a quick guide. It shouldn't be relied on as the only method of testing. There are differences between the simulator and device (simulator is not case sensitive, for example) and the simulator can't provide all functions as the device (compass, camera for example)
There should be no difference between how your code accesses documents directory, etc between the two. As long as you code the correct way (for example, case sensitively), your code should work on both.
When you release to the AppStore, there should be no difference to what you were running on your device. It is just bundled up and signed with the appropriate certificates.
I am trying to test my app on an iPhone 4S. When I build and run from Xcode, the project is successfully compiled but after that Xcode says:
Finished running MyApp.app on MyiPhone
The app perfectly work on the simulator and the provisioning profile works correctly (I tried to load an empty app and it works).
If I try to manually load the app I get this message:
The Info.plist for application at
/Users/*/Documents/App/AppName/DerivedData/AppName/Build/Products/Release-iphoneos/AppName.app
specifies a CFBundleExecutable of AppName, which does not exist.
Where is the problem?
The connection that XCode creates with the device is rather fragile, and can easily be corrupted if anything goes amiss in the debugging test, most commonly if the developer stops a build, while it is being moved to the device.
I have a routine of things I go through, when this occurs. If one doesn't work, I go further down the list.
Check your signing certificates
: This error can occur if you mess around with the certificates too much. Make sure your current scheme uses the Debug signing when making a debug build, and check in your application settings if the current debug signing certificate is a debug certificate. (Not AppStore, AdHoc or Enterprise).
Reestablish connection with the device
: Look under devices in your Organizer. Check if the device you are using is present and marked with a green bullet. If orange or grey, reconnect the device with the USB. For precaution, wait a couple of seconds from taking the cable out before you insert it. It should make no difference if you eject the cable from your mac, or the part connecting your iDevice.
Reactivate development on the iDevice
: Being unaware why this happends, some devices revert to a non-development stage from time to time. Clicking the "Enable development" under Organizer > Devices seems to clear this off.
Flushing XCode device connections
: Something that often is needed, you can simply shut down XCode (and to be safe, close the iPhone simulator as well) and start it up anew. Deleting the debug application present on the iDevice is also a good idea.
Restart your iDevice
: Tedious as it might seem, restarting your iDevice is sometimes needed, since the pipe held on the device might be corrupted.
Restarting your developer machine
: If everything else fails, a restart of your mac is often required. I have never experienced this error without having it fixed by now.
I hope this checklist will help you through.
Try cleaning the project.
SHIFT+CMD+K
Found the same bug in XCode 9 while running the project on iPhone 5s. Clean the project and it will work.
Clean.
Build.
Run.
It's work for me.
I had similar issue. When I run program on iPad2 it compiles and installs app on device, wait for some time, and display an alert. Then I followed steps below
1) Removed that application from device.
2) Disconnected iPad and tried again.
Then it successfully run in device. If this not resolved your issue, do
Rename your application to some thing else and try to run. It will run. Lastly you can make an "ipa" file with Ad Hod distribution and can test on device.
Looks like you are trying to run a release product on the device. You are probably signing it with production key. Run it as debug.
Maybe I'm totally off with this guess but the last time I got the same message was when I had some required hardware capabilities set in the Info.plist which the target device didn't comply with. (E.g. requiring a camera and trying to run the app on an iPad1.)
I've just finished chasing down a similar problem.
An app that worked on the device (iPad 1) and on the simulator stopped loading on the iPad but continued to function as before on the simulator. When "run" with the device as target, it compiles and then goes immediately to "Finished Running...".
I did all the usual bits - removed the app from the device, ran Product/Clean, removed derived data, shut computer and device down cold, but with no luck. Other development apps loaded and ran fine.
This app uses GameKit. When I removed the gameKit requirement from Info.plist, the app loaded and ran correctly on the device again - including the GameKit functionality (no kidding). When I added gameKit back in, it failed again. When I added the gameKit requirement to other apps, they failed to load to the device as well. It appears that something has happened to the gameKit setting on the device, although gameKit is there and functions as always. I'm suspicious that this one has to do with the state of the sandbox.
I've got to make a few changes to get the app running on the iPhone and I'll test that as well. I'll repost if I sort it out.
Si it seems that XCode build, ran and finished but the app failed to be deployed and was not even copied to the device.
In fact, there should be something in the XCode project that is broken. This is easily corrupted. The best move is to build a new project from scratch. Don't forget to add armv6 support if needed.
It works well for me!
Check the device log
It may occur, that you are using a provisioning profile, which does not allow one of the entitlements, listed for your target.
For example
entitlement 'entitlement-name' has value not permitted by provisioning profile 'Your Profile Name'
For me, the usual culprit is that I have an app store build already on my device.
Different/same version numbers might make things worse. I haven't looked into it too deeply since deleting the version that is already on my device usually fixes the issue.
I am developing a blackberry application and I'm trying to get to devices to communicate. I am trying out the SocketDemo app and it shed light into the socket process (which is no different from any other platform so far).
Only problem is I can't test the app since I can't get the app into two different emulators. How do I accomplish this?
If you do not need to hook the second simulator into the debugger (for breakpoint setting, etc), then getting your application to run simultaneously on two simulators can be done fairly easily.
Build your application, and run it from the JDE; standard procedure.
Then, outside the JDE, start another simulator (it cannot be the same one), and, when that's up and running, choose FILE->LOAD JAVA APPLICATION from the second simulator's window menu. Select the .COD of the application you just built. The application will then be installed onto the second simulator, and will either start automatically, or you can start it by clicking on its icon (depending on how your project is set up).
With two simulators on the same machine, with applications that need to communicate through the network, it may be needed to change the ports in the .BAT file that launches the second simulator, before starting it -- otherwise, the second simulator may not be able to bind to the same ports on the machine.
Indeed, with some simulator models, you will not be able to do this unless the second simulator is from a different simulator package (different directory), because the process grabs a lock when it runs.
If you are using a built-in simulator package that only contains one simulator, you can download a second simulator, ideally a different model, from RIM's developer site: http://www.blackberry.com/developers/downloads/simulators/
Have you tried installing different JDE's and trying to run emulators from them?
I just submitted this to Apple Support, but I'm wondering if anyone here has encountered something similar.
SUMMARY: my iphone app crashes when downloaded from the iTunes app store or from an ad-hoc distribution, but doesn't "crash" when run in debug mode on the simulator or on my iPod
DETAILS: The app contains a rather large sqlite database file (~180 meg uncompressed, 56 meg compressed). This may be relevant.
When launched, the application should copy the database (if necessary). After this, the user should be presented with a table-view containing approximately 6,000 rows. The information presented within these rows is derived from reading a table within the aforementioned database.
This all works properly when I run the application in the iPhone simulator and also when I run the application in debug mode on my iPod.
The app was approved by Apple. However, when users began to download the app through iTunes, I began receiving emails saying that the UITableView was not populated with any information. To investigate, I downloaded a copy of the app from the app store and I saw a similar result (i.e., UITableView is displayed, but the rows are empty).
I believe I am able to reproduce the problem using an ad-hoc distribution of my app.
The ad-hoc distribution behaves similarly (i.e. shows no rows in the UITableView) to the app-store download. Specifically, I have done the following multiple times (I delete and reinstall the application each time).
add my ad-hoc provisioning
certificate to iTunes
add my ad-hoc app build to iTunes
sync my iPod Touch with iTunes
start my ad-hoc app
app seems to always crash upon the first startup (i.e., the splash screen shows for a second and then I see the home screen of my iPod Touch)
second and subsequent start-ups of the ad-hoc app do not crash, but the UITableView is empty.
None of this happens when I run the app on the simulator or when I deploy in development/debug mode on the same iPod.
I have tried to examine crash logs associated with the initial crashing of the app (see step 5 above), but no crash log is created at that point in time. HOWEVER, a crash log is created when I sync iTunes with my iPod Touch, but it might as well be written in Polish.
So, it appears as though the app-store reviewers who approved my app only examined the behavior of the application using the simulator and/or in development/debug mode. It's possible that the issue is related to the large size of the database file, but this is complete speculation on my part. To the best of my understanding there should not be a limit on app-size or database size near 180 meg. This also wouldn't necessarily explain why the app works in debug/development mode.
Has anyone seen anything similar?
I think I figured this out (haven't tested it yet)...
Turns out the entire crash log isn't written in polish.
There's a part that says that the "application failed to launch in time"
I suspect that my database is too large to be copied during launch of the application.
to quote apple: ***iPhone OS uses a watchdog timer when applications are launched. If an application takes too long to complete its initial startup, the operating system terminates the application. Applications terminated for this reason will have the exception code 0x8badf00d and related information noted in the associated crash report:*
*When Xcode launches an application, the watchdog timer is disabled to compensate for additional overhead that may be incurred when Xcode attaches the debugger. As a result, your application's long startup may initially escape your attention if you are exclusively testing by running from Xcode.***
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