Disclaimer: Apple has been uncharacteristically awesome about dealing with me through this issue. I have filed standard bug RADAR reports as well as contacted a member of the Apple Music team (who shall remain nameless) more than once. In all cases, responses from the mothership have been prompt, helpful and non-dismissive. I hope other developers have similar experiences, regardless of outcome.

iOS 11 is stressing me out.

If you’ve been wondering why Cesium’s development cycle appears to have slowed down over the last 6 months or so it’s because A) we moved, but B) the next version of Cs has had by far the longest beta run of any update I’ve ever put out. That’s because 3.9 fundamentally changes the way Cs handles playback, and I want to make as sure as possible that you never notice. I’ve also been waiting for a (minor if you’re Apple, major if you’re me) bug in the iOS 11 beta to be ironed out. It’s becoming increasingly likely that that’s not going to happen.

Why?

Queue management in iOS is painfully difficult. You can’t actually modify an existing queue; you must replace it entirely. That means that Cs does a lot of background tracking and storing so that for every queue modification (add, delete, reorder, shuffle, unshuffle, everything) it can figure out where you are in the queue, what changes need to be made, and then reset everything accordingly. Even worse, the process of setting queues with large numbers of tracks is brutally slow, and must be executed on the same processing thread that handles UI. Take a cruise through Cs’ 1-star reviews. All those complaints about freezing? Those are people whose UI gets locked up while the system queue is loaded. Version 3.9 has been on beta for so long because it completely overhauls Cs’ approach to queueing: moving to a rolling queue that only loads a subset of tracks so these freezes are less (if not totally un-) noticeable. It’s a substantial change, and a ton of testing was needed to get it performing (mostly) identically to the old method.

That means nothing to me. What’s the problem?

In addition to UI lag when setting queues, it also affects playback. Obviously playback can’t continue if there is no playback queue, so resetting that queue can result in a short gap in playback. If you’ve been using Cs for a long time (or used a competing alternate player) you probably remember what I’m talking about. Fortunately, I discovered a little loophole in iOS that allowed for seamless playback at the cost of some backend complexity. From a user perspective everything was working great! On iOS 10.

iOS 11 breaks that loophole. As of iOS 11 Beta 7, setting the playback queue restarts the currently playing track, every time. This can be mitigated somewhat by capturing and resetting the current playback time, but the gap is still there. And as we get close to September, it becomes increasingly unlikely that this issue is going to be resolved.

So what does it mean?

Here’s what you need to know:

Apple has confirmed this is indeed a bug. That doesn’t mean it will be fixed, but at least it’s on a list somewhere. Hope springs eternal.
The tide rises all boats. Because this is a system bug, it will affect any version of Cs, and any other third party player that has some form of queue management.
Your only way to avoid the issue entirely is to stay on iOS 10. I hate to be that app, but at the moment it’s true. If Cs is your deal breaker app, I’d recommend delaying the update to iOS 11 and watch this space.
Cs 3.8.7 and Cs 3.9 will be impacted differently. Because of the changes in queue management within Cesium, the bug manifests in different ways. It’s hard to say which will perform better for your workflow, with one exception…
If gapless playback is essential to you should NOT update to 3.9 AND iOS 11. Gapless playback will work fine in v3.8.7 on either iOS. And gapless will work fine with any Cs version on pre-iOS 11. I am working on a solution that will allow gapless to work properly on iOS 11 and will update as soon as I solve it.

Next Steps

The ball is totally in Apple’s court right now. There doesn’t appear to be (even according to Apple) any way to work around it. We just have to watch and wait. I’m remaining optimistic for the time being, but if iOS 11 hits Gold Master with the issue present I will begin reworking Cs (again, ugh) to minimize the issues as much as possible.

I will update this post as the situation progresses.

UPDATE 1: A user has logically raised the question "Why not just drop Apple Music support? Why sacrifice performance for a feature you can't really support fully anyway?" It's a great point, and one that sparked a shockingly (if you are me) one-sided poll on the subject, and a bunch of weekend work and thinking about how a switch to AVPlayer would be implemented. It makes a lot of sense. An AVPlayer driven app would address a lot of the little issues and complaints. Unfortunately, after exploring it I've (re)discovered that that switch would not only drop AM support, but Cloud support in general. And I'm not prepared to go that far.

UPDATE 2: Issue is still present in Developer Beta 8.