Putting earth-shaking world news aside for a moment: the BIG news in our little iOS developer bubble over the past couple weeks has been the official addition of mouse and trackpad support in iPadOS 13.4. For various reasons, I think most of us love the idea of being able to use our iPad as a “computer” — with Xcode for iPadOS being the holy grail we’re all longing for — and this is a big step in that direction. On top of that, this is not your standard, run-of-the-mill mouse cursor; Apple has, in some subtle but significant ways, reimagined and redesigned the pointer on iPadOS, and the results are pretty exciting.

Naturally, iOS developers and designers far and wide are now scrambling to figure out what this means for them and their apps. There are some new APIs to learn, sure; but perhaps more importantly, there are now a whole new set of design considerations to take into account when building an iPad app, and we all kind of have to collectively figure out what exactly those are. Of course, Apple’s Human Interface Guidelines are a crucial starting point, but inevitably, there’s still a bit of a gap between written guidelines and effective third-party implementation. Twitter pal @_chuckyc got a bit of a conversation going to this effect, and then summed it up nicely here.

I’m not going to dive deeper into these brand new interactions at this point, because I’ve still got some work to do myself to better understand the impact all this will have on building apps for iPad. As for properly adding pointer support to the little app I’m currently building, I haven’t gotten much further than tacking “Add thoughtful pointer support” onto my ever-growing to-do list.

Which got me thinking: we sure are juggling a lot, huh?

Things were pretty different when, on a whim, I decided I wanted to “be” an iOS developer in 2012. For starters, there was one iPhone size and one iPad size, and I don’t think universal apps were a thing yet. There was no AutoLayout, no Storyboards, no Swift or SwiftUI. There were no app extensions, no Watch apps, no Siri intents and shortcuts, no 3D Touch. None of this “multiple scenes” business, no haptic feedback, no drag and drop, no dark mode, and of course, no trackpad and mouse support. I’m sure the list goes on and on — those are just a few things that spring to mind.

These are all wonderful tools and features that improve our lives as developers on the whole, and allow us to build ever-more-engaging and delightful ways for people to interact with our apps. But for the most part, they’re adding to, rather than replacing, existing tools and features, and I wonder: are these all piling up and making the barrier to entry for iOS development significantly higher? Or has this been offset by other improvements to the developer experience? Part of me feels like iOS development in 2020 is a whole lot bigger and scarier-looking than iOS development in 2012. On the other hand, maybe a new iOS developer doesn’t need to care a whole lot about the details of drag and drop, dark mode, or hover states, and in fact, a modern UI framework like SwiftUI is making app development more accessible than ever.

I kind of suspect the reality is closer to the latter, but if anyone out there is just getting into iOS development now…I’d love to hear what that experience has been like!

More to the point: designing and building a great, fully-featured app — one that takes full advantage of the impressive hardware and vibrant platform it’s built on top of — is really quite difficult, regardless of your experience level. I don’t think that’s news to anyone reading this blog, but I thought it was worth dwelling on for a minute. Not to lament the complexity we deal with — I’m hugely thankful I build software on a platform that has evolved and improved so rapidly, and has stayed so relevant, for so long — but simply to remind us all that there’s a lot going on here, and we don’t need to be instant experts on every additional feature and tool that gets thrown our way.

If you’re building an app on your own, all of the design and development complexity falls squarely on your shoulders. If you can write code and make your UI look “nice,” that’s a start, but it certainly doesn’t get you to the finish line — and with each iOS update, the race seems to get a little bit longer. In 2012, thanks to the combination of building on a younger platform and truly having no idea what I was doing, most of what I was thinking about was plopping views into Interface Builder, moving things around to make them look good, and hooking IBActions up to my app logic. Today, even an app that seems straightforward on its surface likely has me thinking about:

• Designing layouts that nicely adapt to a wide array of screen sizes
• Making sure my universal app is built according to best practices on both iPhone and iPad
• Supporting Dynamic Type, and ensuring my layouts can handle it
• Supporting a wide variety of important accessibility features
• Using 3D touch in a useful way, without hiding important functionality behind it (though this seems to be on its way out)
• Thoughtfully designing for dark mode
• Properly handling both software and hardware keyboards
• Supporting useful keyboard shortcuts
• Adding haptic feedback (without getting carried away)
• And now…appropriate hover states in my UI for mouse/trackpad use!

Depending on the app, it’s not unusual to also need to think about significant bolt-ons like Siri integration, Today widgets, Spotlight search indexing, Watch extensions, and the like. And of course, this doesn’t even touch on all the more technical complexity in writing code that interacts with networking services, that’s modularized and well-architected and testable, that keeps up with best practices in Swift, etc.

It’s a lot!

Again, I’m not at all suggesting this is a bad thing, nor do I think this is unique to iOS development. But I do think it’s worth taking a step back and recognizing the breadth of knowledge involved in designing and building a great iOS app, both for the sake of celebrating the effort that goes into the best apps on the App Store, and as a helpful reminder when the scope of what you thought was a simple project starts to feel a bit overwhelming.

While I may have a long list of iOS features that I’d love to integrate into my app eventually, I’m trying not to think of it as a checklist that needs to be completed in order for the app to be “finished.” Instead, it’s simply a ranked list of priorities. I realize I could probably spin my wheels for years trying to check off everything on that list, while constantly adding new things to the list as the iOS ecosystem continues to evolve. Instead, in this pre-release stage of development, I’m trying not to worry too much about keeping up with every shiny new tool or feature we get from Apple. There are a few existing features at the top of that priority list that I feel strongly about getting into version 1; anything beyond that can be chipped away at — and probably prioritized more intelligently — once I’ve got some folks actually using the app.

My lofty ambitions are absolutely to get to everything on that list eventually, and build my little idea up into a best-in-class app on the App Store. But, honestly, I get frazzled easily when I feel like I’m juggling too many ideas and competing priorities at once. So, for myself and anyone else who needs to hear it: focus on a few high priority items, iterate, and don’t worry too much about keeping up with the latest on UIPointerInteractions until you’ve got a working app to interact with 😬

Thanks for keeping up with my happy little blog. Stay home, wash your hands, and find me on Twitter here! 🦆