The presentation of iOS 8 was dominated by Apple’s Near Field Communication (NFC) payment technology and the Apple Watch, but from a developer’s perspective, the most amazing thing about iOS 8 is its sheer size. When I started developing mobile applications just a few years ago, one of the things I liked about iOS was its relatively small surface area and lack of clutter. There was only one screen configuration, so layout was easily done with pixel values that corresponded to actual, y’know, pixels.

iOS 8 introduced more than 4,000 new APIs, bringing the total surface area of iOS to somewhere north of 30,000 functions. There are high- and low-level frameworks for 2D and 3D graphics, and another framework for dealing with network games. There are frameworks for manipulating images and different frameworks for manipulating photos. There’s a framework for doing audiovisual programming, and another for recording and playing audio. And another for audio plug-ins. And another that describes audio streams. And…

You get the picture: Our little handheld operating system is all grown up now. It used to be that Erica Sadun’s “iOS Developer’s Cookbook” was pretty much all you needed to program a decent app. Now, although Sadun’s recipes (now divided between two thick volumes) are still indispensable, you’ll need supplements both thin (such as Sadun’s “iOS Auto Layout Demystified”) and thick (such as Bob McCune’s “Learning AV Foundation,” which I am eagerly awaiting).

(Related: Why developers are going to love iOS 8)

Apple Pay, which will likely be iOS 8’s most impactful capability, was not available during the iOS 8 beta period, so I have not had a chance to work with it. However, the API appears to be a simple extension to the PassKit Framework that was introduced two years ago. There is not yet a low-level framework for accessing other NFC capabilities (which is disappointing in contrast with Android), but if Apple Pay integration is as simple as adding a new kind of “PKPass,” it only adds to the service’s potential success.

“Watch Kit,” the framework for the Apple Watch, is not yet available to developers. This is frustrating, not only because we’re all eager to develop wrapps (Wrist Apps. I just made that up, but it’s pretty good, huh?), but because it is an acid test for iOS’ architectural design in the post-Jobs era.

The watch user experience is radically different from the tap-and-drag user experience of the iPhone. If the watch, like Apple Pay, slots nicely into the existing frameworks (particularly UIkit, the framework primarily responsible for the user interface), it will be an excellent confirmation of the iOS architecture’s ability to deal with the variety of user experiences that Apple clearly wants to deliver (for instance, car interfaces, TVs, and heads-up displays).

If, though, “Watch Kit” requires yet another strategy for laying out interfaces, or reinvents too many view-controllers, transitions, and delegate classes, it will highlight the downside of releasing eight operating system versions in seven years: legacy cruft. Interface layout on iOS has already involved physical pixels, then logical pixels, then auto layouts and constraint solvers, and now size classes. That’s the most obvious area where iOS is beginning to show legacy baggage, but there are also multiple APIs for network access and discovery, image manipulation, styling and laying out text, etc.