I am building an app targeting iOS 8.0 that needs to download files that are up to 250Mb. I had a version of the download code roughly working using Alamofire but I recently replaced that with a pure NSURLSession implementation. This new implementation is working as expected in the simulator and on my iPhone 5S running iOS 9.2 (13C75). It works on my phone whether I install through XCode and a physical connection or through TestFlight. I have deleted the app, restarted the phone, and reinstalled and it always completes downloads correctly. One of my colleagues pulled the code and was able to successfully simulate it from XCode.
However, downloads fail on all of my collaborators' devices. They are installing the app through TestFlight and are set up as internal testers. One collaborator also has a iPhone 5S running iOS 9.2 (13C75). The Alamofire-based implementation worked as intended when deployed through TestFlight to those same devices and very little other code has changed.
I have added some remote logging and I can see that on the failing devices, downloads are correctly triggered and the download tasks I create each have a taskIdentifier which I can log. However, none of the NSURLSessionDelegate or NSURLSessionDownloadDelegate methods are called.
What suggestions do you have for troubleshooting?
Is it possible that this could be related to a TestFlight problem? My current next step is to try an alternative to TestFlight. Ultimately, I would like to be able to deploy betas through TestFlight if possible.
I'm using Swift 2.1.1 in XCode 7.2 (7C68).
The problem turned out to be that I had set the NSURLSessionConfiguration discretionary property to true. The docs state the following which sounded good to me:
When transferring large amounts of data, you are encouraged to set the
value of this property to true.
But I failed to appreciate the consequences of the rest of the text:
For example, the system might delay transferring large files until the device is plugged in and connected to the network via Wi-Fi.
The reason that installations through XCode were working was presumably that the phone was either being charged because it was connected to my computer when I started a download or had just been charged.
I initially suspected that the problem came from either TestFlight or something about the state of the phone. Remote logging with Sentry (which I already use for the backend) was very helpful for getting some insights into what was different when my collaborators ran the app. I eventually added in implementations for all the NSURLSessionDownloadDelegate methods to log which ones were called. This led me to see that didReceiveChallenge was the only delegate method being called and I then spent some time thinking that it could be an auth-related problem and troubleshooting in that general area.
Finally, I started noticing that my own install would fail sometimes and one collaborator had a successful download. That made me start thinking about the kind of phone state that could prevent a download. I went back to the NSURLSession configuration that I had and that's when I read about the discretionary property.
In retrospect, carefully checking the configuration would have been a good step to do earlier. Another good thing to do would have been to log the state property of the download tasks that were created.
Related
Two years ago I developed an iOS app which makes HTTP requests instead of HTTPS ones. I had to add the Allow Arbitrary Loads value in my info.plist for this to work. The app was submitted and uploaded to the App Store and was working well until these days.
Recently, I made some improvements in other sections of the app and submitted a new version. I tested it in simulator and in an iPad an everything was working well until I archived it and generated the IPA file in Xcode. Testing this file in the same device, when I use a function that calls a HTTP request, the request gets stuck and never ends.
As when testing from Xcode everything goes well, I can´t see any error. Any idea? Has something changed recently in relation whit this kind of calls?
Update
Found that Archiving uses Release config and my tests were made in Debug, I started playing with the different build settings and detected that enabling the "Testability" option in Build Options makes everything work again. The Xcode description for this option is:
When this setting is activated, the product will be built with options appropriate for running automated tests, such as making private interfaces accessible to the tests. This may result in tests running slower than they would without testability enabled.
I don't understand the relation between this option and the HTTP requests... Can I upload the app with this option enabled?
As no other answers are being posted, if someone comes here looking for one: I had to enable "Testability" option in Build Options for Release. For me it looks like a bug and maybe this could be corrected in future versions.
I have a need to update my managed app running on a large amount of iPads without any user interaction. These devices all have the managed app locked in Single App Mode. As I understand it, it's an iOS limitation that an app cannot be updated if either of the following conditions are present:
The app to be updated is in the foreground.
Any app is locked in Single App mode.
With our use case, both of these conditions are present. I also understand that the current workaround is to do the following:
Disable Single App Mode.
Enable Single App Mode for a different app (e.g. Safari) to bring that app into the foreground.
Disable Single App Mode.
Update app.
Re-enable Single App Mode for your app when the update finishes to bring it back into the foreground.
While this method works, it has a lot of drawbacks:
It's highly manual, we have not found a way to automate it. This is especially a problem as the number of devices becomes large. Internet connections can be spotty and there is no robust way to ensure that each step has executed for all devices.
It's prone to failure. Especially between steps 4 and 5 above. It seems there are little to no guarantees of when/if an update was successful to know definitively when to re-enable Single App Mode.
It fails for devices that are offline at time of update. If a device does not have internet connection when the update is executed, there is no way to guarantee that the steps execute fully and in the correct order the next time the device comes back online.
I am looking for a scalable solution to reliably update my managed, Single App Mode app running on thousands of devices in an automated way with no user interaction. I am using Meraki for an MDM right now, for what it's worth.
With iOS 11.2 you can now push a silent update to a device with it running SingleApp mode.
Apple failed to mention this to the public but is included in the beta notes.
Called Enterprise Support today, They could not find any official documentation mentioning ios 11.2.x supports the updating of apps while in single app mode :(
Now with iOS 11.3 beta it is working again but after updation, app is not automatically locking in Single App mode we have to restart device.
Hope in upcoming beta's this issue will get addressed.
iOS 13.1 beta 1 seems to fix most of the issues I have been having in this area.
I had seen issues in iOS 11-12.* where updates sometimes worked, but sometimes showed a pin-pad even though no passcode or guided access code was set, or otherwise behaved strangely.
In the 13.1 beta 1 you can push an App update and nothing will happen on the device, but if you send a restart command afterwards the device will restart, update the App and continue in single app mode.
I have tested with both 'Single App Mode' (SAM) and 'Autonomous Single App Mode' (ASAM) and it has worked every time for me so far.
This works for my use case as you can push the update anytime and schedule the restart at suitable time when the device is not in use.
edit: 13.1 beta 2/3/4 changes this, now when you push an update from your MDM the App will close, update and re-open and continue in single App mode. I checked both SAM and ASAM both now update without the need for a restart.
Having perused many other questions concerning unusual app crashes without any success at solving my problem, I have decided to post this question.
I have an app that crashes at random. Some users (in test) never have crashes, others have an occasional crash. This app is installed via XCode on testers phones, straight from the development machine. The app never crashes when in use, only upon startup a day or two after installation and use.
The app is instrumented with Crashlytics, and no crashes are detected, nor are Out Of Memory warnings. No crash logs are left on the phone after this behavior.
Crashlytics works. I injected test crashes and they were properly detected.
Once the app crashes, it will not restart. The splash screens appears for an instant and then the app closes.
The app uses Core Data and I use ObjectiveRecord https://github.com/supermarin/ObjectiveRecord as the Core Data interface. There are no aborts anywhere in the code (at least none that I added/left in)
The app downloads about 1500 images (photographs) at initialization time, and whenever the photos collection is updated. The filenames are stored in Core Data, not the binary data.
As an experiment, I took the container from the same app on another phone and replaced the container on the defective phone. No difference. Replacing the container on the good phone with the container from the bad phone made no difference either.
If I reinstall the app on the target phone, without deleting the original install, all works as expected. This leads me to believe that I am not suffering from database corruption - obviously, I may be wrong, but if advice can be offered as to how to test this, I will happily accept it.
I am at my wits' end here - any advice as to what the problem might be, or how to diagnose the problem will be gratefully received.
EDIT -- The app is for IOS 9, iphone only.
I shall answer my own question. I have been distributing the app to my 4 testers using a MacBook. I only have one license, and rather than downloading it and moving it between my iMac and MacBook, I was just allowing Xcode to generate a new certificate.
This doesn't work. Ever.
It invalidated all of the copies of the app that I installed.
The moral of the story is: beware of licensing issues - even if you have a license.
and the hint was:
Aug 29 15:48:28 iPhone amfid[170] : /private/var/containers/Bundle/Application/25BE181B-C30F-41FF-87A3-88C8E63BB3B3/TEST.app/TEST not valid: 0xe8008018: The identity used to sign the executable is no longer valid.
Live and learn I guess......
I've integrated CloudKit into my iOS app and I'm encountering functionality inconsistency between devices.
One of my users has an iPod 5th Gen and an iPhone 6. If they use the iPod everything works as expected. However if they use the iPhone 6 they can only receive data and notifications, they can't make changes of their own. When the iPhone attempts to make changes to the iCloud public database I receive no errors and changes are made locally, they just never make it to the server (everything appears to work, it just doesn't).
Given that the user can use the iPod successfully but the same iCloud account only receives data on the iPhone suggests to me that this might be a permissions or settings issue.
I've checked:
User is logged into iCloud
iCloud drive is on
The app appears enabled in the iCloud Drive menu in settings
The app appears enabled under the "Look Me Up By Email" menu
Other details:
The app is available through TestFlight
The app is using the production container (required for TestFlight)
I don't know what code to supply because the app functions as expected on other devices but let me know what could help. Any help would be greatly appreciated.
This was resolved by changing my modify operations qualityOfService property to .UserInitiated.
After I reviewed the completion handler for my CKModifyRecordsOperation I realized that I was saving data necessary for local functionality regardless of whether the completion handler received an error or not (and incidentally, whether it was executed or not). So when it appeared to me that my operation was being run and returning no errors, it actually wasn't being run at all. Changing the qualityOfService appears to have resolved this.
Answer that led to the solution
I am working to add a TopShelf implementation to my tvOS app. I am also working to create a Collection View implementation that has a similar functionality from within the app. Both work fine in the simulator on my Mac but don't work when deploying to my Apple TV using TestFlight. I tried using the USB-C cable to try to capture some logs or see what is going on when the UIActivityIndicator just spins. I thought it could be related to trying to download too many images or some other networking issue. I started caching the images and again that works well in the simulator but not on the device.
When I plugged into the device and ran the app it worked as it should, even with a higher number of downloads. I later updated the version via TestFlight and was back at the same position. Right now I am in a position where the app works every time with my own view controller and the TopShelf part, but does not work at all if deployed via TestFlight. I can't get any logs to figure out what is going on because when I connect the USB cable and run the app, it starts working.
Has anyone seen similar behavior or know of any way to troubleshoot what is going on?
I was able to determine there were a couple of things going on. The first was that the simulator was setup for a build configuration of debug. I went in to Edit Scheme and changed the Build Configuration for Run to "Release." This allowed me to recreate on the simulator what I was seeing on the device. It also made it a lot easier to debug as I could easily add logs to track down where the code was hanging.
The root of the problem was that I had a while loop doing nothing while I waited for a network block to update a flag. I've used this hack in other situations and have never run into a problem. If I added one NSLog command to the while loop it would flow through fine, but with nothing in the loop it just hung even though the network dispatch was done downloading data.
To fix this, I read up on using
dispatch_semaphore_wait(sema, DISPATCH_TIME_FOREVER)
which solved my problem (and I'm assuming made my code a lot more reliable too).