What are the concerns and limitations of networking on iOS?

If you think it's only about not blocking the main UI thread, think again!

Most mobile developers think that the main thing to worry about in building out the networking layer of mobile applications is for it not to block the UI as the network requests are issued.

Yes, it is a concern, but not the main one. How your API is structured, how many requests you have to make in order to get or send the data, how complicated and convoluted the API is, how fragile it is, etc., are the real questions you should be concerned with as a mobile engineer.

Another set of concerns is the features the app has and their requirements, and any physical limitations the users might have. Do you need to support an offline mode and sync data later? Do you need to build a request queue to retry them on a spotty internet connection? etc.

The API Structure

There are in general two approaches to the API structure - either go for a bespoke, custom API specifically crafted for your particular app, or go with a generic option that any app can use such GraphQL.

If you’re building a very highly performant and robust API, with a full stack vertically integrated team, you’re better going with REST API architecture (or similar). It will give you the best overall results.

If you don’t have a full stack team, and don’t really know your specific use case yet, going with a generic “querying” solution such as GraphQL is the way to go. It will give you the flexibility with your API but at a cost of poorly optimized performance and potentially complicated networking layer - if the API is not optimized for your use case, you might have to make multiple calls instead of one to achieve the results you want.

Feature Requirements & Physical Limitations

If you need to build an app that would work well in a field with a spotty internet connection, then your biggest concern would be the connectivity and retryability of your requests. (Maybe even implementing offline features or queues dwelling into the storage layer would be an option.)

On the other hand, if you're building an app for consumers that are always in an office or at home with a great internet connection you'd probably be able to get away with more frivolous networking solution (maybe even socket!) that doesn't cache as much as it would otherwise.

---

All of these are potential interview questions and discussions you could have applying for iOS developer jobs. There is a lot more nuance and details on the “What are the concerns and limitations of networking on iOS?” interview question above in the 2nd edition of The iOS Interview Guide book I’m working on.

Subscribe to hear more updates on the book’s progress, or sign up for the waitlist on https://iosinterviewguide.com/ to only hear about big “official” book updates such as when pre order starts or when each chapter is updated and released (I’ll also post those updates here on The Mobile Engineer substack too).