iOS 9 Spotlight fail fixed by killing background Reeder.app

iOS 9.2 Spotlight has been driving me crazy on my iPhone 6. I use search to start many of my apps, and at least half the time nothing would show up. I think this started with iOS 9.1, but it got worse with 9.2. I saw complaints about this on Apple Discussions, but I knew it wasn’t affecting everyone. There was something odd about my setup.

Of course restarting the phone would fix the problem, but only transiently. I tried various maneuvers to rebuild spotlight indices; for a time I though removing Contact search was the key. Sometimes disabling Spotlight search for all applications seemed to help — but then it would fail again.

Then I noticed something interesting. Sometimes, after entering a search string returned no results, if I waited a bit, canceled the original string, then reentered, I’d get part of the Spotlight results. Maybe not any of my apps, but perhaps Spotlight Suggestions would show up. Sometimes I’d even see the app list, or Spotlight would show the default “search the web” UI then refresh and show search results.

It almost seemed like Spotlight was trying to work, but something was slowing it down. Perhaps if it’s too slow to respond Apple’s iOS 9.2 code times out. So, even though I have ‘Background App Refresh” disabled, I wondered if a background App was interfering with Spotlight.

So I started emulating my #1 son and routinely swipe-closing (killing) background Apps. (Yes, I know this is supposed to be a bad habit. Except when it isn’t.) After I’d killed 20 or so Spotlight started working again.

With a bit of trial and error I found I only needed to kill one. I only had to kill my #1 most used iPhone app, Reeder 3 for iOS. Spotlight then worked every time.

I don’t think this is a Reeder bug. I suspect it happens when background apps are somehow tying up Spotlight indexing, even when indexing and background app refresh are both disabled for a specific application. Other apps may do the same thing, but since I follow hundreds of Feeds and have Reeder running constantly, I probably see this more often than most. I think there are multiple iOS multitasking management bugs going on here; I’m just glad to have a relatively painless workaround. If you are seeing this problem but don’t use Reeder then do experiment with killing other backrond apps.

Reeder.app has a Sync:Background Refresh setting that I’ve now made “manual” only. I’ll update this blog post when I find out if that works.

A Google Doc I wrote in 2010 has lost its images

Every 1-3 years I write a “solstice letter”. Since 2010 or so I’ve used Google Docs; it’s the best match to sharing it via PDF and web. 

Today I discovered the 2010 document has lost its images. The text is there, but the images are gone. I tried downloading as PDF, but they don’t show there.

It’s a significant non-recoverable Google Cloud data loss, probably related to old versions of Google Docs.

I’d saved a local .docx version to my personal web site so I still have something like the original. Because I’m a particular kind of paranoid; that is, the experienced kind.

Not good Google. Not good at all.

Emergent phishing attacks

This one amused me.

I have an email address in one of my domains that redirects to an immutable long-random-username address assigned by Appigo. Messages to that address create tasks on Appigo’s ToDo.app [1]. Today when I opened ToDo.app I had a task that included a phishing attack link. The “Dear xxx” introduction included the username portion of my redirect task.

This clearly wasn’t a specific ToDo.app phishing attack; it was a routine email phishing attack. Gmail would have sent it directly to spam, but of course this route bypassed spam filtering. Having a phishing attack appear on my task lists was an emergent result of using a “secret” email address as a data interface.

The good news is that the email redirection I used is also a form of defense. Appigo doesn’t provide a way to change their secret email address (not smart of them), but since I created a short memorable version their immutable “backdoor” was not exposed. I can change the redirect address I control.

Intelligent systems are rather hard to secure. Which is why the Internet of Things is a mistake. Make no system smarter than it needs to be…

[1] I use this app extensively on iOS and OS X, but I don’t recommend it because there’s no data export or archiving support. Of course most of the competition are no better, but OmniFocus and Toodledo provide export.

The Apple Way or the Google Way: A rough draft for comment

I’m writing a book on supporting special needs teens and adult independent living with a smartphone. I’m covering both iOS and Android in the one book (if Microsoft pays me I’d do them too :-), so I had to write a chapter comparing them. Except that’s not what I had to write, when I started I realized that I wasn’t comparing iOS to Android as much as I was comparing the Google Way (Android, iOS) to the Apple Way (iPhone).

I’ve done a very rough draft below, I’d love to get comments here or email to jfaughnan@gmail.com (or jgordon@kateva.org if you prefer). By way of context we’re an iPhone/Mac family who do most things the Google Way, and while I do appreciate my iPhone 6 (screen pop!) I’ve been quite impressed by an ultra-cheap Lenovo moto-e phone I bought for this project. I think Apple used to do great software, but they lost that knack around around 2006, when Steve Jobs killed iMovie 6/iMovie HD. So it’s a fair fight now.

Life would be simpler if either the Apple Way or the Google Way were clearly better. Unfortunately, life isn’t like that. So there’s no simple answer to the question “What phone should my Explorer use?”.

In general Guide and Explorer should use the same smartphone. Very few people will want to know learn the ins and outs of two devices. So if you and your Explorer favor the same solution you can skip the rest of this discussion.

School experience doesn’t help much. Most schools, even those that favor iPads over Chromebooks, use gCloud services. This tends to favor Android phones, where gCloud is the only option. On the other hand, as we noted earlier, iPhones can be used with Google’s solutions — it’s just a bit more complicated.

There’s a cost advantage to Android phones, but it’s not as big an advantage as it first looks. If you disregard the deceptive cell phone contract “costs” and look at the real cost of an unlocked phone, you can buy a remarkably powerful Android phone for as little as $100. The least expensive iPhone currently costs about $450. That’s a big difference, but even a good mobile phone plan will cost $40 a month (more below on saving money there). Over two years the Android device will cost $1,920, the iPhone will cost $2,270 or 15% more. At the end of that time the iPhone probably has 2 more years of useful life, but the Android phone will be obsolete. Of course if your Explorer tends to lose or break phones, that $100 phone is awfully appealing.

The iPhone has other advantages that justify some of that price premium. Apple Stores provide excellent technical report and service. iPhones get regular and reliable software updates and are much less vulnerable (so far) to malicious software attacks (malware). If you stick entirely with iCloud iPhones are significantly simpler to use than Android phones.

Apple’s software is typically easier to use and learn than Google’s software. It’s also easier to restrict and control an iPhone. Those are real advantages for our users.

In theory, for a vulnerable population, the iPhone with iCloud (not gCloud) has other advantages. Google makes its money from advertising and selling information about its software users, Apple makes money from selling goods and services. In practice I’m not sure how much different this makes … so far.

There’s one last consideration. If you choose an Android device and gCloud it’s not hard to switch to an iPhone. Google wants your advertising attention regardless of what device you use; you can bring gCloud with you. If you choose an iPhone and iCloud though, a move to Android will be more painful.

The good news is that whatever choice you make, you can easily defend it! Both Android and iPhone will work. Just try to avoid supporting both and Android and an iPhone. That’s too much work.

How Apple's Music.app broke shuffle in iOS 9.2 (and how to unshuffle your classical music album)

With Music.app in OS 9.x Apple effectively made “shuffle” the default way to play an album or playlist. That’s not necessarily bad, but where they went off the rails was they gave one icon two very different behaviors. To explain how to shuffle I have to explain what they did

This is the problematic icon:

On this screen, which is what you see if you tap the new default wee summary screen that shows when music is playing, it behaves like a toggle:

That is, if you see this screen, you can turn shuffle on or off by tapping on the shuffle icon. It’s a toggle. The color change is too subtle, but if you squint you will see it. Of course this means you have to start playing a song to change the shuffle state and then you have to go back to the album and somehow start over. Very weird. Really only makes sense if you’re in the middle of a playlist and for some reason you decide not to shuffle any more. Why would anyone do that?

But that’s not the real problem with Apple’s UI. This is the real problem, it’s the screen you see if you tap an album or a playlist:

Do you see our old friend the Shuffle icon? It’s mid-way down. It even has the word Shuffle next to it — a convention that appears nowhere else in Apple’s iOS user interfaces. Except it’s not our old friend. in this context “Shuffle” is not a toggle. It means “start playing what’s below — shuffled”. There’s a control that means “start playing what’s below — not shuffled”; it’s the small pink play arrow that appears above Shuffle (sometimes I think it doesn’t show, but that’s probably a bug. Stop what’s playing and return). This other control actually is a toggle, between play non-shuffle and pause.

So on this screen, to recap, there are 3 functions, play non-shuffle, play-shuffle, and pause. The functions are distributed between two controls, one a toggle and the other an action button, and the action button uses the same icon as a toggle control that appears on another screen.

[UPDATE: If you are in the context of a list, as when you select an album or playlist, and your are not in shuffle-mode, then if you select the first item on the list play will continue sequentially until the list is completed. This behaves the same way as taping the Play icon on the Album Art image when no item is selected.]

Yes, there really is a horror movie to be made about Apple’s software development post 2010.

Incidentally, here’s the official 9.2 user guide as of Dec 2015. They don’t even try to explain this. Smart move.

Calendar sharing between Google and iCloud is very confusing: webcal vs http vs. https

A book project forced me to dig into a perennially painful topic — Calendar sharing and subscription in iOS and OS X (MacOS Yosemite) for Google and Apple.

I discovered:

• iCloud uses Webcal protocol links to share public calendars among iCloud users. Google can parse these, but it in my tests no events appeared. Old web pages say Apple blocks Google access to public iCloud calendars (robots.txt).
• Google uses https links to an ICS file to share public calendars. Yosemite Calendar.app can use these links and iOS Calendar.app can use these URLs [1], but iCloud.com Calendar can’t. At least in my testing, with Yosemite, Calendar.app on MacOS and Calendar.app on iOS don’t share these calendar subscriptions.
• Safari.app on iOS will pass an iCloud webcal URL link to Calendar.app and this will trigger a calendar subscription. Google ICS file (https) links won’t work, renaming them to webcal doesn’t work either (I think it might have in the past).

This confusing situation is reminiscent of the complex hoops required to support CalDAV sync for multiple Google Calendars in iOS and MacOS. Apple and Google have very different models for calendaring and they also appear to have different approaches to implementing CalDAV (and they’re probably on different CalDAV versions too).

 

On balance I much prefer Google’s approach to managing Calendars. On the other hand, if one stays entirely within iCloud and ignores Google calendar sharing, then Apple’s Calendars are simpler to use and understand and are better documented.

 

Don’t bother trying to share a public iCloud Calendar to the world, when Apple says “public” they really mean “iCloud”. If you do want to subscribe to a Google Calendar on your iPhone or MacOS, you will have to do it separately on every device you use (it my testing these subscriptions do not sync, I do hope they are backed up).

 

If you are sharing a Google Calendar, you’ll want to provide directions for iOS and MacOS users and you’ll need to explain that they won’t be able to see the calendar using iCloud.com.

 

Sample links used in my testing:

iCloud Public Calendar Share link:

• webcal://p32-calendars.icloud.com/published/2/5ti02pRya1_rzpjcGlbr6DG8IOGsbgGKgWeeQsd6LJUi4Gck7Bqt8kyitXCNeVGJLFzY_0DshIikKkgevKPAffxkcAr_SBrL_63VWujM5I4 

Google Public Calendar Share link:

• https://www.google.com/calendar/ical/kateva.org_7fnk4q97156l5rqdgvd3mshpis%40group.calendar.google.com/public/basic.ics

- fn -

[1] Documentation: Subscribe to a calendar. Go to Settings > Mail, Contacts, Calendars, then tap Add Account. Tap Other, then tap Add Subscribed Calendar. Enter the server and filename of the .ics file to subscribe to. You can also subscribe to an iCalendar (.ics) calendar published on the web, by tapping a link to the calendar. The second part of this documentation is incorrect, you can only subscribe for a webcal URL and only iCloud seems to produce the “right” ones.

See also (references)

• Gordon’s Tech: Google’s Calendar Sync with Mountain Lion through Yosemite Calendar.app is a flaming mess 10/2013
• Use multiple calendars - iPhone - 12/2015
• Subscribe to calendar by link does not work in ... | Apple Support Communities
• Techniques to Share Apple and Google Calendars - Envato Tuts+ Computer Skills Tutorial
• iCalendar - Wikipedia, the free encyclopedia
• Webcal - Wikipedia, the free encyclopedia
• How to share or make iCloud calendars public on iPhone and iPad | iMore
• iCloud: Calendar sharing overview
• iCloud: Share a calendar with others
• iCloud Calendar sharing to iCal4 or CalDAV client | Physics Computing Services
• Gordon's Tech: MobileMe vs. Google Calendars 10/2010

iTunes audiobooks: something actually worked

I’ve had such poor experiences with recent iTunes and iOS audiobook support my expectations are pretty bleak. So imagine the shock when something worked.

I recently ordered an audiobook from the Great Courses (aka The Teaching Company. Incidentally, never pay list price. They routinely have 70% discounts). It took me a while to sort out their cryptic download UI — you need to go to ‘My Digital Library” and then click on the book icon to view all tracks, then download one track a time. Once I was done with that I had a set of files in a folder. There was nothing in file names to show they were audiobook tracks; I assumed iTunes would treat them as music and I’d then have to fix the metadata up using Multi-Item Edit.

That’s not what happened. I dropped my folder into iTunes’ My Audiobooks pane and it showed up as an audiobook! Not only that, but the track titles showed correctly; I’ve gotten used to seeing just file names.

Incredibly, I saw the same thing after syncing to my iPhone. Proper book metadata, lectures in order, proper titles. 

Something actually worked. I’m not used to that…

See also:

• Audiobooks not showing in iOS 8.4 iBooks? That's because they're still like Movies used to be. Also, The Great Courses.