My Core Values
I always spent time making sure that the foundation for the project is solid. I separate reusable components into packages, which are then heavily tested, to speed up the process and make sure the building blocks of the app are reliable.
Surprisingly (rather not), the balance between testability, flexibility and scalability is a very tricky one. But when the code is done right, with respect for the application domain and specific requirements, it can hit all of these goals.
Good iOS engineers know so much about their domain, iOS concepts and approaches, that they usually have a bigger picture of how to think about designing apps (things like dynamic type, accessibility, dark mode, etc.). And sometimes by knowing deep technical details, we know what can be achieved in uncharted territories (like Apple Watch complications). I always aim to be involved in the design process, making sure that the app feels at home on the platform.
The sense of community is particularly strong in software engineering, thanks to the open source culture we have. iOS community is known for its principle of balancing new ideas with time-tested approaches, and I never stop learning from this community. I always strive to learn from people who share their visions, and am never afraid to give back by writing articles, giving talks or sharing my code.
My Strongest Expertise
I spent lots of time working on one of the early-days Swift Server Side projects, Zewo, and it exposed me to numerous new ideas and perspectives, and allowed me to explore Swift with all its powers and capabilities. I know how this incredible language works with full detail, always staying on the cutting edge by embracing newest powerful features as soon as they come out.
While working on Women’s Football 2017 app, one of my main goals was to build a first-class experience for Apple Watch, providing meaningful complications for every possible watch face. I spent a lot of time diving deep into the technology, making sure that every complication family is supported, updates in real time, and never truncates crucial data.
Spending a lot of time studying NSOperations, URLSession and general networking principles, I was always focused on creating scalable and reliable networking stacks. I have experience creating systems with retry strategies, smart caching, background download and upload tasks, etc. Networking is a huge passion of mine and I always keep my hand on the pulse of what’s new and best.
My WWDC 2018 Submission App, Paperville, was built entirely using Core Animation. It features interactive parallax, multiple layers, shadows, rich animations and much much more. Having access only to old iPad hardware, I spent a lot of time fine-tuning the performance to maximize FPS, learning a lot of technical nuances of Core Animation. Core Animation is an incredibly powerful tool and I’m always extremely happy to work with it, with all its fun and weirdness.
I’m spending an embarrassing amount of my free time still trying to figure out what the best approach for persistence is. Having experience using Core Data, Realm, or even creating my own library for lightweight persistence, I realized that the best approach always depends on the app. There’s never a one-size-fits-all solution, and so I always make sure to choose the right tool for the job.
I adore Core Data. Many think it’s too complicated, but I appreciate the fact that Core Data is one of the main reasons why Apple’s own apps are so fast and performant. I spent a lot of time diving deep into Core Data, learning from such great minds as Marcus Zarra and Dave DeLong. Core Data is never an easy choice, but when done right it can be a huge win for the project.
Select Content
You need to be extremely transparent in your codebase of where your data is coming from. If you want a responsive iOS app — make a majority of data calls asynchronous. If you don’t want to change your whole app to use asynchronous paradigms — use Core Data. But don’t fool yourself into thinking that disk is fast enough.
…We can’t rely even on ourselves to write
[weak self]in every part of our app (where needed), and we certainly cannot expect all our potential API users to do the same. As API designers, we need to care about safety at the point of use.
It’s just that on iOS, lightweight persistence doesn’t have its own level of abstraction. The system solutions lacks uniformity, flexibility and they tend to expose a lot of implementation details to us, sometimes making the code that depends on it untestable.
The goal of Shallows is to provide that missing level of abstraction.
Recent Projects