Thoughts on iOS app development from a former game developer

For the last few years, I’ve been working as an iOS developer. Before that, I worked in game development for 11 years, and I thought I’d share a few thoughts and experiences from this shift.

Please note that this is just based on my own experiences, and is enormously dependent on both the types of games I used to work on, as well as the apps I’m currently working on.

Your mileage may vary.

ABOUT ME

My game development experience consists of QA/testing (including certification testing for Sony & Nintendo platforms), level and game design, scripting (proprietary language), and programming (C/C++). I have worked on 20ish published game titles across PC, Sony PlayStation 3, Nintendo DS/3DS and iOS/Android.

I also have a bit of experience with Unreal Engine and VR, as well as some hobby projects in Unity (C#).

As for apps, I’ve mainly worked on the OneCall, MyCall and Mixit apps, in Swift 5 (upgraded from Swift 4). These are consumer apps for mobile phone subscriptions — check usage, purchase products, etc.

SWIFT

When moving over to native iOS development, I obviously needed to learn Swift. I had never used it before (or even heard about it!), but given my previous experience, it felt fairly easy to grok the basics.

Swift is a more high-level language than I was used to, and it took a bit of time getting used to chaining filter, map, reduce, etc. together. There’s a lot of good to be said about the productivity gains this affords, but I had to do some work to become comfortable with it.

One of the things I consider a real killer feature is the guard keyword, especially combined with optionals and guard let. From my C/C++-perspective, this felt like pointers, but without the normal pitfalls associated with trying to dereference null pointers accidentally.

Speaking of pointers, it was very strange moving to a language where they weren’t a big thing. I had moments where I was looking at the code, thinking “but I just want to change this single variable, and I know where it lives!”, to no avail.

In the long run, this has helped improve my project architecture and data flow setup in general, since I can’t just pass various pointers along.

I find working with strings more finicky at times. While not a very typical use-case in everyday development, there are times where it would have been nicer if I could just subscript into a string to access specific characters directly.

I know the reasons behind why it isn’t supported, and I can understand the rationale (which is also why I’m hesitant to reintroduce it with custom extensions). Every once in a while I do still miss the functionality, though.

Aside from those small nitpicks, the biggest hurdle was learning Apple’s frameworks (UIKit, etc.), not the language itself. I had a lot of questions along the way, like “What is a UIView?”, “What does translatesAutoresizingMaskIntoConstraints do?”, “How do I properly configure a UITableView?”, “Why is my Storyboard UI setup completely broken?”, etc.

Colleagues really helped me out here, answering my questions, sending me resources, as well as pair programming/code review sessions.

All in all, I really enjoy programming in it and currently consider it my favorite programming language.

MATH

App development has required less math, and significantly less complex math at that. For the most part, it’s been simple percentage calculations, some animation-related number tweaking, etc.

I was used to doing a lot more physics math, and I haven’t really felt particularly challenged by anything specific so far.

Of course, this is highly domain specific, so I can see this being very different for other projects.

I’ve also been reminded that other developers might not have the same math terminology I do. “Lerp” isn’t necessarily a term that makes sense to people — even if they are quite capable of solving problems where it would be relevant.

ARCHITECTURE

For most of the games I worked on, there wasn’t a lot of post-launch support (patches or extra content). In contrast, the apps I’ve worked on have been continuously improved and worked on for several years. This has been an appreciable difference, with more focus on maintainability and improvement.

This has bled into most things, from comments and documentation, to general software architecture and thoughts surrounding data flow. This is especially true given Apple’s frameworks, and how & when code paths run.

I’m used to keeping track of more state for various entities and animation values, updating them every tick and manipulating them a lot more directly than what I typically do now.

In many ways, SceneKit/SpriteKit is a more familiar setup for me, and I do still at times find it somewhat tricky to diagnose why certain callbacks fire (e.g. the various UITableView delegate or layout functions).

In addition to SceneKit/SpriteKit, I also believe my experience will come in quite handy for anything related to VR and AR, although I haven’t done anything interesting with it in any app as of yet.

Most interesting apps these days have some sort of connection to the internet which they leverage in order to bring value to the user. Most of the games I was involved with were purely offline ventures, with everything being available locally.

This meant that considering loading states was suddenly a different ballpark — data could suddenly take a vastly different amount of time to load, errors are more common, etc.

Network calls in general were also fairly unknown to me, and authentication/tokens was something I’d heard about, but not really needed to understand to any great degree.

USER EXPERIENCE

When developing games, one often creates some sort of design language that acts as a bridge between the game world and the user. While still sharing common elements (a button is usually just a button, even if it looks different), games are often about the fantastical and unique.

This means a lot of custom menus, transitions, animations and sounds, to a larger extent than what I’ve seen in native apps (which tend to more strongly follow Apple’s guidelines and user expectations).

A game by design consists of challenges for the player to solve. As game developers, we intentionally put things between the player and the player’s goal. The obstacles are (hopefully!) fun enough and well-balanced enough that the players strive to complete them, but failure can often be a vital aspect of the overall experience.

In most apps, it’s a very different world altogether. Apps are generally built to solve a very specific task — the user shouldn’t need to overcome challenges in order to listen to their favorite podcast.

APP STORE SUBMISSIONS

Submitting to App Store Connect and getting an app approved by Apple is incredibly easy compared to what I was used to on the Nintendo and Sony platforms.

Certification on these platforms could easily last months if multiple submissions were required (and they usually were!), and the requirements were incredibly strict.

Enable a certain hardware feature for a game, and you could end up with 20% more certification criteria you needed to pass.

As an example of a failure reason I experienced:

We saved the player’s progress through the game intermittently (the save taking less than 1/60th of a second).

The platform holder notified us that, if the save was interrupted somehow, the error message we displayed was incorrect.

We also had to include documentation on how the save game was stored (with memory addresses) as part of the submission process, and they went through and corrupted specific bits of data to see whether or not the documentation was correct, and if we handled corruption correctly.

Contrast this to what you deal with when submitting to App Store Connect, and it shouldn’t be a huge surprise I prefer the latter.

MISC

In addition to the more concrete differences I’ve discussed above, there have also been a variety of “softer” changes.

Certain terminology is completely different — I was used to “design” referring more to how a game or level worked in terms of mechanics, while artists created the graphics, UI, etc.

There are a lot more departments involved. Coming from a fairly small game development company (roughly 15 people at its peak), there’s suddenly marketing departments, product owners, and much more to deal with, which was a new experience for me.

All in all, shifting to app development has been incredibly interesting, and I still feel like I’m learning and improving my abilities continuously.

That’s it for now. Thanks for reading :)