iOS and .ics

Dear Lazyweb,

Is clicking on a link to document of type text/calendar believed to work on iOS? Using https:, not webcal:, that is, "event attachment", not "dynamic calendar subscription".

If so, do you have an example of one that works?

Because mine appear not to. Mostly Safari just does nothing, but sometimes it pops up a dialog saying "Download Failed, Safari cannot download this file."

Related question: if Safari was logging an error to syslog on my phone, how would I see it? If it's in "Xcode / Window / Devices / Device / View Device Logs", I don't see it. That seems to only be crash logs, not general syslog verbosity.

Tags: , , , ,

22 Responses:

  1. ssl-3 says:

    If I may piggypack your Lazyweb request:

    Does any of this calendering stuff really work, anywhere, at this point?

    I seem to recall having better luck with a Palm Pilot a million years ago in terms of simply getting things added automagically to my personal calendar.

    • Aaron says:

      It's never not worked for me since I set up a Baïkal CalDAV/CardDAV server in 2012. That's across multiple versions of iOS, OS X, and Thunderbird with the requisite plugins (Lightning and SoGo Connnector). It even worked with no trouble on the Android burner I once briefly had to put up with, where it was especially notable for being basically the only thing that did.

      I can't speak to iCloud, Google Borg Services, or any other provider, but "if you want it done right" et cetera has worked out brilliantly for me in this case. If you're willing to invest a few hours (tops) initial setup effort and a few bucks a month (tops) for hosting, it might work for you too.

    • Jeff Clough says:

      If your needs are relatively minimal, and you surrender your information to the hive mind/clown, then yes, it works reasonably well.

  2. UnlikelyLass says:

    I have an iPhone 5c running the current version of iOS (9.3.1). Clicking on your example link in safari brings up a dialog with event details with a button which said 'add to calendar'. Pressing that popped up a 'select which calendar to add to' dialog. Selecting one has resulted in a calendar entry now being visible in the iOS calendar app.

    One wrinkle: my calendar is not an iCloud one -- it's Google. But regardless -- the above link works for me as is.

    • UnlikelyLass says:

      Well! Clicking it a second time prompted me to delete it.

      Clicking a third time and selecting an iCloud calendar also worked, but clicking a forth time prompted me to add the event again, not to delete it.

      So it's clearly not behaving itself entirely.

      But it did add the basic event in both cases.

  3. andr00 says:

    Related answer:
    Yes, those are just crash logs, and there is a limit of how much of them the device will store.
    To view the console on iOS devices, I use this free OSX program.
    You plug a device in to a machine running the program, the log pops up.

  4. hop says:

    Have you changed something since posting?

    Because the link works perfectly fine in Safari on iOS 9.3.1.

  5. ff says:

    You should be able to get a streaming syslog-ish view in Xcode->Window->Devices->(your device) but you may have to click that little up-arrow-triangle-in-a-square near the bottom left of the main part of the window to reveal it.

  6. Steve Allen says: is an Internet Draft related to this issue. The reasons (i.e., the failures to interoperate) behind this are getting discussed on the IETF calsify list, see the thread containing this

  7. I cannot download a well formed file from the link. It stops mid word near the end.
    0013720 n E N D : V A L A R M r n E N D
    0013740 : V E V E N T r n E N

    • jwz says:

      It's working fine for me...

      • Jon Lennox says:

        I see the same thing, downloading to my Android phone.

        Unsurprisingly, the various calendar apps I have refuse to parse the vcalendar.

        • jwz says:

          Well if you are getting a truncated file, that's not surprising, though I don't understand why that would be. wget consistently gets me the whole file, and Content-Length and Content-Type are both correct.

          However if you have a non-truncated file, ending with "END:VCALENDAR", and you have something that won't parse it, I'd be very interested to see any error messages you can coax out of that.

          • Jeff Clough says:

            For shits and giggles I just downloaded the file with Chrome on Windows 10 and also got a truncated file. This is the text at the end:


            Here are my request headers...

            Accept-Encoding:gzip, deflate, sdch
            User-Agent:Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.110 Safari/537.36

            And here are the response headers:

            Content-Disposition:attachment; filename="codeword-20160420h.ics"
            Content-Type:text/calendar; charset=UTF-8
            Date:Sun, 10 Apr 2016 17:41:55 GMT
            Expires:Sun, 10 Apr 2016 18:11:55 GMT
            Keep-Alive:timeout=2, max=100
            X-XSS-Protection:1; mode=block

            The length of the (incomplete) file is 6,123 bytes on disk, which matches the length of the response header I'm getting.

            • jwz says:

              Ugh, the Content-Length was wrong because of unicrud! That took a while to figure out, because I was measuring in characters instead of bytes, so it looked fine in emacs...

              And wget usually downloads the whole file regardless of Content-Length.

              • Leonardo Herrera says:

                I believe I read an article titled "Content-Length Considered Harmful" on teh intarwebs once. Wonder who wrote it. Meh, probably not related.