I’m working on an iOS app right now with a feature that uses images from the Photo Library. This was all solid for me, and I had worked with it for a nearly a month before putting it before my alpha testers.
With a set up like that, you know where this is going: It totally did not work for them. At all. After the users would pick a photo from the library, the spinner letting the user know an image was being loaded would sit there forever, and eventually, this would show up in the console logs:
May 19 14:51:17 THE-MOON SpringBoard : MultitouchHID(1ed4d440) uilock state: 0 -> 1
May 19 14:52:00 THE-MOON SpringBoard : jotunheim has active assertions beyond permitted time:
identifier: CoreLocationRegistration process: jotunheim permittedBackgroundDuration: 600.000000 reason: finishTask owner pid:725 preventSuspend preventIdleSleep ,
identifier: CoreLocationRegistration process: jotunheim permittedBackgroundDuration: 600.000000 reason: finishTask owner pid:725 preventSuspend preventIdleSleep
May 19 14:52:00 THE-MOON SpringBoard : Forcing crash report of jotunheim...
For the life of me, I could not reproduce this bug on my phone or my girlfriend’s phone. Which, of course, is bewildering. Googling pointed to a lot of problems related to threading, and indeed I was using a dispatch queue of my own making to do the image work.
I know there’s things that absolutely must be started on the main thread: Network calls (which end up on the web thread) and UI stuff. But I wasn’t doing anything with the network or the UI, as far as I knew. And why would this only happen on my users’ devices and not on devices in my household?
I’ll spare you a recounting the red herrings that I surveyed.
It’s because the first time you try to get stuff out of the Photo Library with ALAssetsLibrary, it asks the user if your app can have access to location data. (Photo metadata can contain with location data.) But it can’t show a UIAlertView from a thread other than the main thread, it can’t, so things will just stall out.
My phone and my lady friend’s phone have had on them previous builds of the app that used ALAssetsLibrary from the main thread. So, back then, that dialog was able to show, and location data access permission was saved. Deleting the app doesn’t revoke that permission. The current build, which used ALAssetsLibrary from a non-main thread, ran into no problems because it had the permission and didn’t need to show any dialogs.
The lessons I can see are:
1. Doing work in helper queues is great, but think twice about whether or not the things you do there are going to lead to UI or network stuff.
If I had read carefully, I would have noted that the documentation says:
When the asset is requested, the user may be asked to confirm the application’s access to the library. If the user denies access to the application, or if no application is allowed to access the data, the failure block is called.
2. Things that affect your app get saved outside of your app and don’t get cleared when you delete your app.
I hope this saves someone somewhere some time.