Intive Blog

The Highlights of Swiftable 2019: Project Scalability and Accessibility

Technology conferences aren’t new for programmers. However, not many have had the opportunity to attend the Swiftable conference, which claims to be the biggest and most important Swift and iOS development event organized in Argentina.  

The two-day event featured renowned speakers like Félix Krause (creator of Fastlane), Haiyan Ma (creator of Undercover) and Sally Sheppard (accessibility consultant and developer), among other personalities of the industry. Most of the topics discussed were technical in nature, others purely anecdotal and some versed on the philosophical, but today we’ll comment on the ones we found most interesting. 

Organizing and Scaling Up a Project 

The speakers worked in different companies and even came from different countries. One of the topics they focused on the most was scalability and organization of large projects. 

When we say large projects we refer to those that involve more than 70 members divided in different teams, which often work in geographically distant locations. The members of such teams are writing code simultaneously and implementing their own code review processes and unit testing.  

Our teams have no more than 2 or 3 members, and if someone breaks a functionality when committing, it isn’t that serious and can be fixed. But when there are dozens of people working in the same project, such problem takes on a larger scale. What’s the recommended solution? Dividing the project into smaller and independent sections.  

We’ll now discuss a few variants to this proposal. The issue is the same, the spirit of the solution remains untouched but the approach can vary. The thing is, there will never be a perfect tool; we should think of it instead as a process of continuous improvement where better solutions come up that work best than the previous one.   

  1. Dividing the app into multiple projects: this means that each section of the project can be compiled individually, so that the total time for compilation is significantly reduced. How many of you have spent more than 5 minutes compiling with Xcode, because it has to index everything again? Imagine doing that for an app with thousands of lines of code. In addition, dividing the app into modules helps to reduce the risk of breaking the code in other parts of the application 
  2. Pods. In our opinion, this is even more advanced and complex than point number 1. The application is not only divided into projects, but also into dependencies. This decouples the code and turns its components into versionable objects. Let’s suppose that a commit makes a serious damage in one of the application’s components and needs to be fixed as soon as possible in order not to block the rest of the team. By simply lowering the version number of that component in the pod file, you can immediately revert the damage without resorting to git reverts. 
  3. Feature Flags. This technique can turn a certain functionality on and off remotely. This contributes to keeping components independent from each other, and if there is a problem in production, it’s possible to delete it and then make the appropriate fix.  

The truth is that all of these approaches add complexity and overhead, not to mention the difficulty of including new developers. For this reason, they would only prove useful for huge companies or projects, and in cases where the application has countless functions and flows and a small army of programmers behind it.  

The interesting thing about this type of projects is that at the beginning they don’t implement such processes nor use such tools, but then they start to evolve and try different methods until they find the one that’s most suitable for their goals.  

Make It Accessible 

Accessibility is something programmers tend to ignore. Sally Sheppard addressed this in her presentation “The Accessibility API”. 

When it comes to thinking and also designing functionalities, it’s essential to consider how the application will be used by people with visual or motor impairments. Thinking about this early in the development process, compared to doing it later on, helps to save time and efforts. Apple’s inclusive tools are easy to understand and, with a little effort, can make a big difference for someone in need of them. 

Sally explained how VoiceOver, Apple’s tool for visually impaired people, works in iOS. In order to configure this accessibility tool in the required components, you need to edit their properties. When VoiceOver is activated, these properties are automatically read out loud, which enables the user to understand exactly whats their purpose. Among other things, the properties specify the following:  

  • the type of element (a button, for example) 
  • the action taken (if any) 
  • a description 

Sheppard stressed the importance of accessibility in all applications. As developers, we need to embrace it and convince our clients to consider it for their applications. It’s important to include as many people as possible to use our products. We all benefit from it. 

A T-Shaped Developer 

Haiyan Ma, originally a physics professional, explained how she struggled to apply her knowledge outside the academic world in fields other than physics, something that led her to learn subjects beyond her original specialization.  

She connected that to the concept of the T-shaped developer, which represents the depth of knowledge a programmer has beyond the basic understanding of many topics. This symbolizes the fact that it’s advisable not to focus in one area only, but to be open to acquiring new information from different areas.  

In the development world, we tend to focus in learning only one technology instead of multiple ones, which makes us rather structured. But if you explore other topics as well —and not only technical ones—, you can assimilate other perspectives and experiences that would be impossible to gain otherwise. 

A developer must, in part, keep constantly updated and have a mix of hard and soft knowledge. The important thing is to be able to come up with solutions, as well as to create custom tools to facilitate testing, reduce compilation times, avoid the coupling of functionalities, seek team consensus over architecture and scalability, and promote productivity. It’s on us to learn how to avoid idle times. 

Finally, it’s key to leave the comfort zone and build bonds with the largest community of developers possible in order to design better solutions and thus enrich the world of IT development. 

Agustín Palmeira

Agustín Palmeira is an iOS developer in intive since November 2015. He is a student of Computer Engineering at Universidad de Buenos Aires (UBA), who has been working in the IT sector for a decade. A lover of travelling -which allows him to know new places and cultures-, Agustín has among his main hobbies: practicing volley, going to the cinema, studying German and playing Pokémon Go with his companions at the company.

Daniel Antoriano Takagaki

Daniel Antoriano Takagaki is a software developer at intive since October 2012. Better known as “Taka”, Daniel is a videogame development technician. He graduated from the Multimedia School Leonardo Da Vinci. Besides developing, he actually plays them, having gaming as one of his main hobbies. He is a member of the iOS Brigade in the company. 

Ezequiel González

Ezequiel Gonzalez is IOS developer at intive since August 2011. Videogame developer graduated from Escuela de Arte Multimedial Da Vinci, he worked two years as a QA tester and one year as a prototype developer for Flash games. Ezequiel´s hobbies are drawing, reading and playing videogames. He also goes to yoga once a week and excercices at home.

Add comment