This past summer, I had the opportunity to intern with a notable tech real-estate market company. I joined their iOS team as a Software Development Engineer Intern. The team is responsible for developing and maintaining their real estate and rentals apps on iOS devices. My project was to develop a Commute filter, which allows users to filter properties based on various parameters to a specified point of interest.

I built the feature primarily in Swift and a bit of Objective-C, using XCode as my IDE. Prior to the internship, I had very limited iOS and mobile development experience in general. Much of my learning was done on the job by reading documentation, tutorials, internal wikis, and picking up on patterns in the existing codebase. I found Swift to be a very neat language, as it has elements of just about every programming language I had used to up to that point, including enums, closures, and optionals. It also has guard clauses, allowing for early returns in a more attractive and readable fashion that clarifies the intent of the code. Overall, it has the easy readability of high level languages like Python and Javascript, while also having the benefits of being strongly typed. I learned that type-safety is imperative when working with a codebase of this scale, where data is being passed around between myriad classes housed in different files.

One key learning I picked up on is the MVVM (Model, View, Viewmodel) architecture, which is the predominant design pattern used throughout the app. In contrast to the traditional MVC (Model, View, Controller) architecture, the Viewmodel serves as the data binder between the View and the Model by exposing data streams from the Model to the View while also responding to View events. The View does not have any knowledge of the Model, and the ViewModel does not have any knowledge of its View. This design pattern helps to decouple UI and business logic and also makes it easy to unit test the different layers.

One challenge I encountered while working on this project was that it involved many moving parts, with dependencies owned by various teams. For instance, I had to call a microservice to autocomplete a search query, another microservice to parse the autocompleted query and return the corresponding map coordinate, and another microservice to take this coordinate along with various parameters to return a filtered list off properties. The backend teams that owned these microservices were often busy with other projects and did not prioritize updating the API contracts, making it difficult to proceed. This required me to exercise some soft skills and leave my comfort zone by frequently communicating with developers outside of my team to inquire on the status of the dependencies. If a certain feature wasn’t ready yet, I had to learn how to reprioritize my own tasks so that I could maintain productivity. Despite these blockers, I was still able to build and test this feature and even hit some stretch goals.

Overall, I had a solid internship experience. The project was well-scoped and meaningful, I was able to go above and beyond with the feature assigned to me, I got to work with numerous teams, I had no shortage of help from my mentor and team, and I had fun learning a new tech stack. It even changed my prior attitude towards iOS development, which originally was not the most positive.