I currently have an application that uses location services and is working great on devices running iOS5 and above. However, have been running into inconsistency issues with 4.3.x.
Problem:
When installing and running the app for the FIRST time, we get the usual 'Allow this app to use Location Services' dialogue to change the [CLLocationManager authorizationStatus]. However, when we uninstall the application (from the home screen) and reinstall the app, we never get this prompt again and somehow the OS has cached the users response for this app, despite this app being uninstalled and reinstalled freshly. On all other versions of iOS, we get the prompt as expected and the [CLLocationManager authorizationStatus] is set to kCLAuthorizationStatusNotDetermined as expected.
Can anyone tell me why with 4.3 the OS seems to remember the options for the app despite it being uninstalled? In order to rectify this issue currently, I have to manually reset all Location Services settings on the device through the settings menu.
If you need any information, or code snippets, please ask.
It turns out this is a 4.3 limitation and is apparent when running an application on any device iOS 4.3.
Apple must have decided this isn't a bug - which is strange seeing as when a user uninstalls an application, why does the OS remember that users selection of permission for a particular app?
No valid workaround available. Just have to live with it.
Related
I am developing an iOS (5.0+) app, which works very fine on 6 different devices in our company.
When we send the build to the customer, they report they have tested it on 5 different devices and the app is always crashing right after launch.
I have integrated TestFlight and Flurry SDKs to track usage and problems.
The strange thing is that no crashes are reported from both TestFlight and Flurry.
I have adviced the customer to remove the provisioning profiles and try to install everything from scratch, which did not produce different results.
The app is in the App Store, approved from the first try.
It is even stranger that the customer reports crashing when installing a TestFlight build and installing from the App Store.
Is the app going to be approved in the App Store if it crashes right after launch?
Any ideas on how to remotely debug the app or how to proceed in this case?
Thanks and happy holidays!
One option is to ensure your logging and get the crash logs. This Apple documentation shows how to get the logs both with and without Xcode available:
http://developer.apple.com/library/ios/#qa/qa1747/_index.html
After you get the logs, here's documentation on how to read and analyze:
http://developer.apple.com/library/ios/#technotes/tn2151/_index.html
The problem has been resolved by adding both German and English localization to the project settings and having 2 storyboards for each language. Big up #RoboticCat!
We are trying to develop an application similar to an existing app currently in the app store.
This app is sending location data in the background to a web service, and the app will continue to run following a reboot of the device. I will also note, that following the app being installed and registered, the location services indictor remains constantly on the status bar. I am assuming this is necessary to allow the app to continue to run following a the device being restarted.
We have tried using the "UIBackgroundModes/required background modes for location", and have been unsuccessful in having the app continue to run following a reboot of the device.
Can someone please point us in the right direction as to how to have the app continue to send location data following a device reboot.
Thank you very much!
No app will run following a device reboot. It is not possible to build a file daemon under Apple's SDKs. You'd have to jailbreak the phone and run unauthorized stuff to do so, then you wouldn't be accepted into Apple's app store.
Yes your app will be restarted if your are monitoring significant location changes or monitoring a region and that region is entered/exited.
In iOS 7 Apple made an important change that will disable these mechanisms if a user force quits your app. They will remain disabled until the user starts your app again.
I've answered two different questions now, both explaining how VOIP apps don't start on start-up, yet people seem to think they do.
I'm not 100% sure myself, someone linked me to a part of the apple docs, which doesn't really mention anything about auto-starting of apps.
I was originally going on prior knowledge and this answer, but after another person saying that they do, I'm really not sure.
As far as I'm aware, apps only react to push notifications, and can't be launched into the background when a device is turned on.
Can we please clarify whether it is possible to auto-start an app or not?
Take a look at the UIBackgroundModes section in this document - it seems to state that adding the voip key will autostart an app on boot.
Edit: a sample app seems to confirm this behavior.
I confirm that setting VOIP mode works. However, I've found that the app won't restart after power up unless it was running when the device was powered off. Furthermore, the app won't actually restart on the recently powered up device until the device is unlocked after power up.
OK, I don't know if this classifies as an answer but I feel obligated to say. I am developing an app that both tracks significant location changes and provides VoIP features. The app has voip key in Required background modes. I tried some cases which I would like to share the results:
App is in Debug mode - Turned off while app was running (active or background) - iOS 7.1.1 (11D201) and iPhone 4 (product name: iPhone3,2):
When booted, app is running in background, as well as other apps that were running before. I do not think this is related to VoIP in any way.
App is in Debug mode - Turned off while app was terminated - iOS 7.1.1 (11D201) and iPhone 4 (product name: iPhone3,2):
When booted, the app is not running, there are no logs in configuration utility, server says the user is not registered I cannot call it from other devices; and yet the other apps that are not related to voip or location tracking but were open before turning off are at least loaded in memory. Meaning, the voip key did not work.
I have continued the test with the same app but this time downloaded it from app store. The results are the same. Changed the device and os to iPhone 3G (product name: iPhone2,1) and iOS 6.1.6 (10B500). Nothing changed both in debug and release modes.
I have told my boss that Apple provides this behavior and it can be done. Then I had second thoughts and tried, now I am desperately trying to find another way. Going to send my regards to Apple about this.
You can not launch an application without user interaction. The user has to click on the app icon, on push notifications, on a custom link. May be there are other ways I am not aware of, but even if they exist, they require user interaction to intentionally launch the app.
Edit
It turns out, as Tim mentioned, there might be an exception for VOIP apps.
I have been developing VoIP apps and I can confirm that VoIP app will autostart when iPhone reboots as long as user doesn't kill it before reboot. When iOS autostart voip app only application:didFinishLaunchingWithOptions: will be run, i.e. applicationDidBecomeActive: won't be run.
I used to doubt whether iOS will automatically restart the voip app when it crashes. After investigating I find iOS does automatically restart the voip app but if it keeps crashing iOS will then try servals time before it finally gives up.
If you check iPhone console output from xcode, you can see logs like these after the first crash
..
Service exited due to signal: Abort trap: xxx
Unable to get short BSD proc info for xxxx: No such process
Application 'UIKitApplication:xxxxx]' crashed.
...
Significant location change or region monitoring also causes an app to launch on boot as long as its turned on and left on. No UIBackgroundModes key is necessary for this.
Anyone having problems deploying Enterprise apps on iPhone/iPads running the released version of iOS 5 using the OTA ("over the air") methodology?
During the installation process, we get the alert box: "the app could not be installed at this time". Tapping the Retry button does nothing. In some cases, repeated tapping of the Retry button eventually results in a gray, empty launch icon being left on the home screen. No app installed. No other errors.
Anyone else seeing this or have a resolution?
The below description is a bit involved, but please bear with me as it may help others who run into the situation. I will post the resolution if get a resolution from Apple. So far, no joy there.
Our app refuses to install OTA on iOS 5. This same app WILL install on iPhone/iPad devices running iOS 4.x.x AND the same app will install on iOS 5 devices physically connected to a desktop machine using the iTunes app.
The Apple Developer forums under the IOS 5 Beta category complained about the problem but no indication of resolution as of last week just before the official release of iOS 5.
Cookies are set to be accepted.
Bowser cache and history cleared.
Using mobile safari originally installed with original iOS version 4.x.x.
System hardware and operating system configuration
iPad 2, iPhone 4 or any iPhone device running iOS 5 RELEASED version.
Browser and version
Mobile safari that is installed with iOS 4 on ipad2. Don't know if mobile safari upgrades with ios 5 upgrade.
Using a corporate wifi network. Yes, we are behind a firewall and use a proxy server. Since iOS4 devices install without problems, I don't think installation being blocked by the proxy or firewall.
Enterprise app built with Xcode 4 and ios5 sdk provided with it. Built to be backward compatible with iOS 4.0.
Distribution provisioning profile is correct as we have been using it for several weeks.
This app installs properly on iOS 4 devices both over the air and via iTunes application method.
This app installs properly on ios5 devices through the physical connection with iTunes application on the Mac desktop.
Steps to reproduce:
User types in the URL in mobile safari on iPhone/iPad running ios5.
The resulting webpage shows the download app link.
User taps on the link and is asked if they want to install the app.
User taps the yes, install button.
App proceeds to install.
A gray launch icon shows up on the home screen with the progress bar empty at the bottom of the icon.
Message below the icon indicates "loading".
Seconds later, user gets the "cannot download app at this time" error message as seen in screen shot attached.
Tapping the retry button results in the same action just described.
Tapping done results in the download stopping.
If you tap retry several times, user sometimes is left with the gray empty launch icon, which will not launch and cannot be deleted.
Note: In the apple developer forums, under the iOS 5 beta category, people are describing the exact same problem with no resolution.
Had the same problem, and was able to resolve it. However, the error noted is not specific to a single cause that handles every case... some detailed investigation needs to occur.
Your best bet is to connect the device to your Mac, and using the Organizer of xCode view the console logs while you are attempting to do a wireless deployment. There will be some useful information available -- please post the logs.
For my case -- the icon files were missing from the build, as a result of moving from xCode3 to xCode4 and also, the distribution plist was referencing an image that returned a 404. Both were logged in the console, but not very clearly.
Also, as a sanity check, manually verify the URL to your IPA file also.
I had this same problem and was sure everything was correct in my project; but restarting Xcode and doing a clean revealed my Enterprise scheme had somehow defaulted to the wrong provisioning profile.
Re-selecting the correct profile and re-archiving the app fixed the issue for me, I'm able to install an enterprise app on both iOS4 and 5.
I wanted to chime in after fighting this for a few hours. It is iOS 5 specific.
We had an htaccess password protection on the directory. Removing this allowed the app to finally download. So if you have htaccess, perhaps you can point the user to a parent directory that is password protected, then navigate to the subdirectory containing the app that isn't password protected. This is a temporary solution, apple needs to fix this.
Another thing to consider is the URL you specified in your over-the-air Application.plist file. I received the same error message ("-application- could not be installed at this time") because the URL I specified was too unspecific. Rather than writing "directory/directory/application.ipa", I had written "directory/directory/". You must include your application in the complete URL of the plist file's configuration.
If you didn't do this, don't fret! You don't have to rebuild the entire thing from step one, you can open your .plist file in any standard text editor and simply change the URL.
We had the same thing.
Our mistake was to point to a wrong 512.png icon in the manifest.
Which was no problem on iOS4 but turned out to stop iOS5 into a "...at this time" alert.
Wanted to chime in on my experience.
In my case, we were changing the address where the IPA file was hosted. Although I updated the PLIST file with the proper URL to the IPA file, iOS was still going after the old URL almost as if it cached the PLIST data. Creating a copy of the PLIST file and renaming it resolved the issue (data within the file remained unchanged)
I met the same problem today. The app can be installed in ios4, but failed in ios5 with "** could not be installed at this time" alert.
According to patricksan's suggestion, I download iPhone Configuration Utility 3.5 for Mac OS X, and try to catch the log while install the app through OTA.
The log helped me finally, one sentence of the log says entitlement 'get-task-allow' has value not permitted by a provisioning profile. It remind me that if the code signing identity in build settings of Project and Targets are correct, after checking them in Xcode, I found the code signing identity are not correct one, they should be iPhone distribution:.... other than iPhone developer:..... After correcting them, and re-Archiving the ipa file, it can be installed in iOS 5 now.
Check your Info.plist for Required device capabilities property. I recommend to delete completely this property if you haven't any restrictions on use.
There's a bug in OS 4.1 that has broken location services for some iPhone apps ( https://devforums.apple.com/message/306250 ). Basically location services fails to turn on, and doesn't even ask the user for permission to get their location. The worst thing about the bug is that it doesn't occur when you're installing the app to a device from XCode, it occurs you when you're downloading from the App Store! This makes it almost impossible to test for a fix.
Not everyone's app has been affected, so I'm trying to find out what causes it.
Does anyone have any location services code that's NOT affected by this problem? In other words, who has code for an app that has location services working fine on OS 4.1 devices, when installed from the AppStore?
Thanks!
Tristan
I have found a workaround-Solution: Reset the location warning. (Settings > General > Reset > Reset Location Warnings)
I have seen this occur with apps I have developed when the device has installed a testing version provisioned under a distribution profile and then installs the final version submitted to the app store. The symptom is that Location Services never seems to initialize or ask for permissions and you wind up never being called back with a location or an error to handle.
We have verified that rebooting the device does NOT fix it, but that resetting the location warnings does. In our testing, this only affects devices that ran developer provisioned builds and not 'pristine' devices that only install the App Store build.
I worked through this with the apple help people. Resetting location warning didn't work. Resetting the network didn't work.
Basically, I reset the phone in itunes and set it up as a new phone. The location now works.