Recreating the Apple Music Now Playing transition

[warrenburton]

A common visual pattern in may iPhone apps are stacks of cards sliding in from the screen edge. You'll recreate the Apple Music Now Playing Transition

---

This is a companion discussion topic for the original entry at https://www.raywenderlich.com/221-recreating-the-apple-music-now-playing-transition

[dmitry_varavkin]

Track names are great! Thank you for tutorial!

[sbouchard]

Hi,

Great lesson !

Is it possible that for the iPhone X, the part about Hiding the Tab Bar we need to adjust the bottom constraint to the superview and not the safe area? The animation is a bit strange if you use the safe area in my opinion

[warrenburton]

Entirely possible. Give it a go and see what happens. I have a feeling the iPhone X animation wasn’t as good as it could be. Probably to keep the tutorial simple I let it go.

I do remember that there was a good reason for binding to the safe area when I built the tutorial.

The tutorial is meant to be a cookbook of techniques for animations and I hope it’s offered you a set of tools for your future apps.

Thanks for reading

[daris]

Hi there, great tutorial.
If its possible an Objective-C version of the tutorial would be really helpful as i am in need of using this function in my application.

Thanks in advance.

[warrenburton]

Sorry no. RayWenderlich.com only do iOS tutorials in Swift now.

There’s nothing Swift exclusive in the code so you could convert to Objective C if you wanted to.

Swift does interoperate with Objective C perfectly in most cases. This code isn’t any exception especially as it’s based around UIViewController subclasses.

Good luck.

[daris]

Cool! Thanks for your response.

[sbouchard]

Yes, the modification for the iPhoneX work well in my case! And to answer your question, yes this tutorial gave me another vision for what I can do with transition animation, and help me understand more deeply the intricate options for future animation.

Thanks for sharing

[anwserman]

@warrenburton, why are the tutorials only in Swift now? Swift as a language has incompatibilities between Swift 2 vs Swift 3 vs Swift 4. I understand that if there is a lack of manpower, to keep to just one language.

I can’t help but feel that until Swift is fully matured and annual code upgrade-breakages becomes a thing of the past, that saying ‘Swift only’ is premature.

[warrenburton]

Hi Jeffrey

Opinions follow. Im not speaking for the site. Maybe drop Ray an email if you feel strongly about it after this.
…

Im guessing that the tutorials are all in Swift because Ray, who owns the site decided to go all in on Swift for Apple development fairly early.

IMO its a good decision as people who want to learn iOS dev will want to learn in Swift. The number of people wanting to learn Objective-C from fresh now will be fairly small. You need to go where the puck will be, not where it was.

As each tutorial has a production cost it might be the difference to staying in business or not if the site attempted to do both Objective-C and Swift. It would also make for bloated confusing tutorials.

Its true that the breakages between Swift 1,2 & 3 were severe but that should have stopped at Swift 4 as the Swift team claims to be making no more breaking changes. I.e. the Swift 5+ compilers should always compile Swift 4.2+ code.

As time goes on and the site periodically updates you’ll find fewer Swift 2 or 3 based tutorials. We have a fairly large iOS team and most tutorials will be updated over a period of time.

Cheers
Warren

[ptlu]

@warrenburton Thanks for the great tutorial!

I wanted to create a slight modification to this set-up and wanted your advice how best to achieve it!

What I am trying to achieve:

• The effect is that the whole mini-player looks like it expands.
• Every element on the mini-player I want to animate – either into position or fade if not needed. This would be in addition to the song cover image.
• This mini-player will exist on every screen of my application.
• I am targeting something that looks very similar to Overcast:
  
  

Questions:

• Since all of the controls will be duplicated and animated does it make sense to have a separate mini / maxi view controller and rather just expand one?
• Are there any major implications of not presenting another scene and expanding in the current scene? Or should you basically always present and use an backing image?
• What is the best way to place this on every screen? Do I just embed the player into container view on every scene?

[warrenburton]

Thanks , glad you enjoyed it.

1. I think it makes sense to expand one player rather than have two from the principle of DRY. You’d need to keep any future visual changes in sync if you went with two controllers.
   One the other hand, you might be able to modularise the system with a master controller + several child VC’s e.g the rev-play-fwd might be one VC , the image another, the pager another, the airplay button another etc.

2. The backing image was used because of the shrinking effect I wanted to reproduce. Auto-layout and CALayers dont play nice together so that technique was useful. If i was reproducing the Overcast style I’d probably try to present (overCurrentContext?) over the lower view controller instead.

3. Theres no best way (never is… ) . I would structure a master root storyboard to provide a root VC with a container for the mini-maxi player + a embed container underneath for other scenes that i could embed into. Mini → Maxi would be a case of altering the height of the player to overlay the underlying scene.

Theres no one right way to do these things. The tutorial is a recipe book to provide you with techniques. You’ll get good at these things by doing them and failing. This tutorial took me a long time to write as I went down many dead ends on the trip to the final product. Even now I can see places where it could be better.

Good Luck
Warren