When Poodle Jumper first launched, we only provided services for dogs, but we are expanding to include services for cats, rabbits, hamsters, gerbils, and mice. Last week I finished the changes to the screens, or views as they are known in iOS. Today, I am working on pulling in the new data structure into the app so customers can add their additional pets. I’m going to show you some of that process.
I compare the changes and figure out how to structure it in the app. Do I need to pull data in a certain sequence? If so, how can I write that code efficiently to be as fast as possible and only include the data I need? When I have a plan for how to execute this in the app, I collaborate with Ruben (Web Dev) and Monique (Software Engineer) because they provide parts of the puzzle that I need. Monique creates the data model and the main database where we store information. Ruben creates a web service for the apps to get that data from the database.
The web service Ruben created has all the pet fields (name, species, breed, size, type of food, attention needed, and special care notes) in the same service as the user’s profile. This means that every time I need to refresh one piece of data for a pet, that I have to get all the information for the user’s profile and all the other pets. This isn’t the most efficient way to structure the data, so I have a quick conversation with Ruben (Web Dev) and Camilla (iOS). We come up with a way to break the one big service into smaller microservices.
Knowing the structure of the data allows me to plan how and when I make the app send a request to get the data. This comes with its own set of challenges to overcome.
I don’t have this challenge at Poodle Jumper, but many iOS developers have challenges with their company thinking mobile-first. Mobile-first design means you think about the smallest and simplest version of a feature first so that it will provide a good experience.
It is easy to design large complex screens for a computer, but mobile applications need to be simplified to be usable. This goes beyond the interface. It also includes thinking about how we design the integrations and how we leverage mobile capabilities to have features that aren’t possible with only a desktop computer.
Many design elements in mobile apps aren’t widely used in web experiences. I get to play with animation, transitions, sound, and haptic feedback (that little vibration you feel from your phone.) I love this aspect of mobile devices because it gives me easy ways to create delightful experiences.
The biggest challenge I face as an iOS engineer is also my greatest learning opportunity: keeping up with the new devices, operating system versions, programming language versions, and capabilities that change every year. If it sounds like a lot, that’s because it is.
Every spring, Apple hosts a World Wide Developer Conference (WWDC) where they announce the new operating system capabilities they’ve built. Anticipation and rumors build for months. WWDC is full of demos and training led by Apple’s employees who created the features, but it is not free.
Developers get early access to the new features, and we look forward to playing around with them every summer. In the fall, the new OS version is released to users along with a line of updated or new devices. We have to make sure we know the changes and test the app on the new OS before it goes live to users. Otherwise, the app could break for them.
You don’t need to know everything to get started. Apple provides a lot of resources, training, tools, documents, and even a developer community for us to support each other. You just need to learn how to read documentation, experiment, and try. With everything changing so rapidly, it creates a level playing field for people just starting out. Honestly, this constant state of change is what led me to become an iOS developer. I really love what I do!