Algoriddim djay Engineering Task - David James

Onboarding flow for djay app, including custom finale page.

Supported on iPhone, including iPhone SE (1st Gen), iPhone 16 Pro and iPhone 16 Pro Max.

Portrait and lansdscape orientation.

Minimum deployment target: iOS 15.5

Screencast

https://share.zight.com/yAuNXb2k

Tech Used

• UIKit only
• Combine
• Core Animation - for gradients including CAGradientLayer and CABasicAnimation
• Key frame animations - for finale page
• SpriteKit - for finale page, nodes, particle emitters, actions
• Autolayout - dynamic/animatable portrait/landscape
• UILayoutGuide
• UIPageViewController
• UIButton.Configuration
• NSDefaults and Codable - for onboarding state
• Swizzling for debugging layout

Improvements

Improvements I'd like to make:

• All screens use dynamic text styles, but on the finale this can cause breakage on devices with large dynamic type. I would suggest using fixed font sizes (adjusted for device) on the finale page to accomodate the content better, but I'm open to other approaches.
• Support for dark mode. I didn't do this since there were no designs to follow, and maybe doesn't make sense for this flow anyways.
• Fine tune launch gradient image to match actual gradient layer. (it's actually pretty close right now and not noticeable)
• iPad support, including split screen and slide over (see next)
• Snapshot testing (see update below)

Caveats

• Some content is hidden to accomodate landscape and smaller screen sizes
• Used UIView methods I created: isVerySmallScreen and isCompactVerticalSize -- Since this is an iPhone only exercise, I took the liberty of checking for very small screens (like iPhone SE) and for landscape orientation, in order to have more precise control of layouts. Obviously, this doesn't work for iPad split screen.

Update 1

• Added initial support for snapshot testing the first 3 screens of the onboarding. Video here: https://share.zight.com/2NuO1PYk

Update 2

• Handle dynamic type changes on all screens/orientations.
  • This uses a technique where each view with text (labels, buttons, etc) has a "maximum point size", to make it harder for the user to break the layout when using large type sizes. Additionally, on the finale screen which is more complex, this max point size is relative -- depending on available space. In that case, we use adhoc height and point size ranges, which (depending on text style - e.g. body, title1, etc) provide a realistic maximum. The user has full range of control up to the maximum at which point the fonts are clamped.