iOS 7 Parallax Home Screen & UIKit Dynamics

As both a long time Mac/iOS developer as well as a long time cross-platform game engine developer, I'm being asked a lot about the game-like features coming in iOS 7, and if Apple has lost any grand vision and the ability to innovate. The features I'm getting asked most about are the Parallax Scrolling on the new Home Screen, SpriteKit, and the physics/motion engine available through both SpriteKit and UIKit Dynamics.

Since I'm a long time Mac/iOS developer, I am very familiar with Apple's NDAs, so I will be very careful about what I say. However, enough information is already public that I can answer a few of these questions at a high level.

So let me paraphrase the most frequently asked question I get and use my response to tie in all the other questions I get about physics and Apple's vision:

"What's so special about the parallax scrolling on the new home screen? Can't that already be done with existing APIs like Core Animation and Core Motion?"

The answer is, yes, you can do that kind of stuff with existing iOS technology. In fact, Core Animation and accelerometer support existed since the first iOS SDK so you could do things like that since the beginning. From a technical standpoint, the Parallax Home Screen doesn't offer anything new that couldn't be done before.

Apple's Vision

But for Apple, the new Parallax Home Screen isn't really about Core Animation or Core Motion, but represents a desire to fuse natural-world motion (physics) with animation in iOS apps in a way that will be consistent across all apps on the OS.

When Apple is at its best, they think in grand unified reusable strokes that apply consistently everywhere, instead of one-off tricks. (I'm not saying they are at their best right now, but this is what they do when they are.)

As an example, you can think of the old scrollview rubber band bounce/spring/snap when you hit the end of a scrollview/list. Apple invested a lot of effort to make that effect 'feel right'. But that implementation is private and anybody who tries to reuse it for their own custom widgets (still UIView based) that don't subclass from their built-in behavior (UIScrollview) can't access it. Those people will be forced to reinvent it, and it won't feel/behave the same way unless that person spends an enormous effort reverse engineering every single little detail.

As a bad example, what if you had your own custom display of a list of objects, maybe a a list of cards like from a rolladex? If you weren't using a scrollview or table view, you can't get that bounce. (This is a bad example because you might be able to do this with iOS 6 UICollectionView.) 

But now, what if Apple were to rethink/redesign the bounce to use UIKit Dynamics because it is kind of modeling a natural world/physics effect (spring/rubberband). Now suddenly all their effects can be accessed for all their UIKit controls for all developers to use.

So a better and real example of UIKit Dynamics in action is the new Lock Screen. When you partially drag up the lock screen and let go, it falls and bounces using physics gravity and collision. Now all developers can access the same stuff to do similar things for gravity and collisions between UI views.

But more importantly, Apple does this in their Cocoa APIs. This means Apple will give you high level APIs to do this (i.e. you aren't setting mass, rate of gravity, friction, elasticity, etc). But just as importantly, Apple will lock you out of low level APIs they don't want you to access. While this is terrible for developers who want custom behavior, this allows Apple to enforce a degree of uniformity across all apps. So for example, the APIs could make it hard or impossible to change the rate of gravity, mass, friction, etc. so that all views always fall at the same rate and bounce with the same momentum. 

Uniformity and consistency across Apple apps (especially includes Mac) has always been one of the strengths of their eco-system. UIKit Dynamics is a way they can entice users to add physics behaviors to their UI in apps, but in a way that apps done by completely different developers will still feel consistent with each other (UI metaphors and specific behaviors remain consistent).

Anyway, this is when Apple is at its best. I haven't looked in detail at their API, nor would I be allowed to say anything specific about it even if I did because of the NDA. They could have completely mucked it up for all I know at this point.

What about SpriteKit and physics?

This is really another topic deserving of an article all by itself. But historically, Apple has been terrible to game developers by turning a blind eye to their specific needs. (Example: Microsoft provided a standard game controller interface in DirectX in Windows 95. Why is it 2013 and we still don't have one in OS X 10.8?) SpriteKit is at least finally puts Apple in a position to start understanding the needs of game developers which is a plus. 

But whether SpriteKit has a grand vision that will continue to evolve through OS X 10.15 and beyond, or will be ignored by developers like SceneKit (introduced in 10.8), or neglected by Apple like PubSub, ImageKit, and more technologies I care to think about, I think it is too early to tell. However, given Apple's track record, I would not put SpriteKit in the list of most-likely to endure. And based on what people such as the Cocos2d folks, it sounds like the physics engine is very Box2D inspired. If true, that may suggest a lack of long term vision. Already, Nvidia PhysX is diving into liquid/water physics.

I don't know the behind-the-scenes, but let me suggest this alternative story. What if people got the relationship backwards with respect to physics? Perhaps Apple agreed to put in a physics engine into iOS was because of UIKit Dynamics and had nothing to do with SpriteKit. The fact that SpriteKit gets to reuse the physics engine is icing on the cake. It definiately makes it easier to argue for putting in a physics library into the operating system if the most used framework (UIKit) is using it. Perhaps SpriteKit was waiting on UIKit Dynamics to be deployed. (There have been rumors for years that Apple was working on a Obj-C based sprite engine for iOS based off Cocos2d.)

Apple's Brilliant Business Strategy

As I sit here and type this, I realize that from a business standpoint, UIKit Dynamics is brilliant in that it is a fairly low-risk API for them while both giving them a distinctive competitive advantage, but also potentially causing havoc/chaos/fragmentation in their competitors's eco-systems.

  • If UIKit Dynamics is unpopular, developers won't use it and it will be like it never existed because it doesn't seem to be intrusive into the existing UIKit API (otherwise no existing apps could still work)
  • If UIKit Dynamics succeeds, users are delighted and Apple makes more money
    • Then Android developers (and maybe Windows 8 mobile developers if there are any) will be under pressure to add similar user experiences to their apps
      • Apple's competitors still have way too much crap to fix in their own SDKs and are playing catch up all the time, so they won't have a response (official API) for a long time
      • Meanwhile, app developers will do it themselves
        • By every app developer doing it themselves, they will create behaviors that feel very different between every different app, hence increasing the feeling of inconsistency and fragmentation across the eco-system which lowers the overall user-experience for end users as a whole
  • This will also making failthful porting from iOS to other platforms more difficult

Also of note, Android is having enough problems just getting their basic UI rendering fast, responsive, and efficiently without physics. (Yes, I spend (waste) far too much time working on (fighting) Android and I know all too well about Project Butter.) Adding a physics library that needs to process continuous updates and collisions isn't going to help this.

Copyright © PlayControl Software, LLC / Eric Wing