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.

Some of the new iOS frameworks are very approachable: Scene Kit provides scene-graph-based 3D graphics and is drop-dead easy to use. At least it’s easy until you get into texturing your nodes with shaders written using Metal, a framework for programming GPUs in a subset of C++11 while wrangling the data in and out of the Objective C world.

Between those two extremes are a number of frameworks that, because they’re tackling complex domains, are harder to characterize. Frameworks like Health Kit and Cloud Kit are complex, but it make sense that there is a degree of complexity relating to the privacy and data-integrity concerns of health information or synchronizing documents in the clouds. Exploring both these frameworks also brings the developer face-to-face with a theme of iOS 8, which is improved privacy and user control. From a developer’s standpoint this means more time spent with provisioning and entitlements, while from an end user’s standpoint, it means more security alerts. It’s still superior to Android’s permissions, where ad-based revenue models lead virtually every install to ask the user for Internet access.

I personally think that until Watch Kit becomes available, the most exciting framework for new capabilities is Health Kit. I like the prospect of “owning” my health data, including test results and such things as sleep analysis and workout records, and Apple’s Health app provides an easy-to-use dashboard for watching trends over time.

I was somewhat disappointed that only Apple-approved types of data can be stored in Health Kit, but was overcome with fury when I discovered that the types of “HKWorkoutActivity” did not include “UltimateFrisbee.” I filed a bug report (18156494 on Apple’s Radar Bug Report system) demanding a fix. I expect to receive a response sometime around the time I receive my Apple Watch 2.