NYSwifty conference

Visiting NYC has always been on my bucket list. So, when I heard there was an iOS conference in the city that never sleeps, I immediately contacted my coworkers and few days later, conference and flight tickets were booked ! Let's go to NewYork ! Let's connect with other engineers from around the world, share knowledge, and gain insights into the latest technologies being used in the industry.

Before we delve into the details of the sessions, allow us to offer some context regarding In The Pocket and explain why the upcoming session on SwiftUI and its associated Architecture holds significant importance to us.

At In The Pocket, we are proud owners of Payconiq by Bancontact, one of the largest and most complex iOS native apps. Its complexity lies in its integration with various ecosystems, extensive feature set, embedded client-side logic, and more.

Over the past 10 years, we have diligently developed this app. While there are numerous details we could dive into regarding the technologies and frameworks employed, elaborating on each would require several paragraphs.

One particular area where we have consistently prioritised attention is selecting the appropriate architecture. Our aim is to maintain a codebase that remains sustainable and supports our project's longevity for the foreseeable future. We constantly challenge our team to explore and update our architecture, aligning it with our primary goals and pillars: testability, maintainability, security, usability, and performance.

We recognise that adopting SwiftUI offers significant advantages to our team in terms of faster screen view creation and utilisation of the Preview feature. Additionally, it ensures that we stay aligned with Apple's latest technology for rendering screens on iOS devices.

However, embracing SwiftUI has posed its challenges. While the latest version of SwiftUI provides convenient APIs for coding, it comes with a trade-off of dropping support for certain iOS versions. This presents a dilemma for us as we have a substantial user base that still utilises these older iOS versions. Consequently, incorporating SwiftUI into our project has presented some difficulties, requiring us to address performance issues, visual inconsistencies, and other issues specifically related to those outdated iOS versions.

Hence, gaining valuable insights into SwiftUI adoption is really importance to us. Specifically, we need to focus on selecting an architecture that seamlessly integrates with SwiftUI, rather than resorting to workarounds or imposing an incompatible structure.

Given that SwiftUI introduces a novel approach to UI design and organisation compared to UIKit, we must be mindful of choosing an architecture that aligns harmoniously with its principles. This entails identifying a well-suited architectural pattern that facilitates efficient data flow, effective state management, and seamless UI updates within the SwiftUI framework.

THE SESSIONS

Having attended all of the 16 sessions, we are eager to highlight our top 4 standout presentations. These were chosen based on factors like speaker energy, audience engagement, and topic comprehension, that undoubtedly deserve to be shared.

Session 1. - Technical Topic: Lessons learned from building SwiftUI apps

by Mohammad Azam

  • Swift UI is declarative UI Similar to React and Flutter
  • Choosing the right architecture for your SwiftUI app can be challenging.
  • While MVVM may seem suitable, there were some concerns about it.

With MMVM your source code will become bloated with multiple ViewModels. As most of the apps follows a client/server model where the server is the source of truth, we start questioning the need for numerous ViewModels. The inclusion of an Environment Object inside a ViewModel feels off, especially when you need to inject it into multiple layers to be shared across other ViewModels.

  • It's important to remember that in SwiftUI, The View is the ViewModel which can be a complex concept for iOS Engineers accustomed to UIKit.

We should not make any difference with other platforms: Component in React Native Widget in Flutter View in SwiftUI

Note that just because it's called a View in SwiftUI doesn't necessarily mean it exclusively renders a UIView.

  • SwiftUI is a Declaration language:

At least from an architectural perspective, SwiftUI treats views as data, SwiftUI view isn’t a direct representation of the pixels that are being rendered on the screen, but rather a description of how a given piece of UI should work, look, and behave.

var body: some View { VStack { Text () → Will render a UILabel

`Button() → Will render a UIButton`

`List() → Will render a UITableView or UICollectionView
}
}`
  • A better approach would be to embrace the MV Pattern.

The essence of the MV Pattern is to enable direct communication between views and the model, eliminating the need for excessive ViewModels that only increase project size without providing significant benefits.

It's acceptable to have small validations within a View, but for more extensive validations, it's advisable to abstract them into separate structs or classes and expose the necessary validation functionality.

Example of an HTML Client Side Form Validation (validating input field):


1 single source of truth:

Took it from Apple’s sample Fruta and FoodTruck (WWDC 2020: Data Essentials in SwiftUI)


By adopting the MVVM pattern, we may find ourselves implementing numerous ViewModels. However, in this approach, MV pattern , we can consolidate our data management and logic into a single Model that relies on a single source of truth, which is the server.

Proposed sample architecture for an small inventory app, by presenter: Mohammad Azam


It is important to keep in mind that this article specifically focuses on client/server applications. The architectural considerations and recommendations provided throughout the article are tailored to this particular context.

Testability

Aggregate models can serve as a single source of truth, supplying the necessary data to views. However, when it comes to view-specific logic, it's essential to determine where to place such logic and explore available options for testing it.

If a specific function or group of functions is intricately tied to the model's logic, it may be appropriate to include them within the aggregate root model itself rather than within the view. This approach helps keep the model cohesive and ensures that relevant logic remains encapsulated within the appropriate domain.

On the other hand, for view-specific logic that does not have a direct relationship with the model, it is more suitable to place it directly within the view. This allows for a clear separation of concerns.

If you encounter complex view logic, it is advisable to extract that logic into a separate struct. By doing so, you can isolate the specific piece of code and write dedicated unit tests to ensure its correctness and behaviour.

It is worth emphasising that many software issues arise because the application was primarily tested at the unit level, neglecting comprehensive system-level testing. To ensure a robust and reliable application, it is strongly recommended dedicating time to writing meaningful E2E tests. These tests contribute significantly to uncovering potential issues and ensuring the overall quality and functionality of the software.

Key Takeaway:

Although SwiftUI is the cutting-edge technology provided by Apple for crafting UI elements, implementing a specific architectural design in our project proves challenging.

We are currently in the process of extracting crucial concepts from our accumulated knowledge, but this endeavour is not without its trials. It significantly depends on the team's competence in SwiftUI, the legacy software, structure of the team, flexibility to adapt to new concepts, challenging design among other aspects. This task requires continuous efforts, yet I concur that we can already progress on key points shared on the conference and undoubtedly avoid repeating the mistakes others have made along their journey when stepping on SwiftUI.

Session 2. - Soft Topic: Mobile Infra

by Anna Chiara Beltrami

Mobile Infrastructure Engineer at Spotify

An iOS Software Engineer shared her experience at Spotify, working as a Mobile Infrastructure Engineer.


Definition

  • Mobile Infrastructure refers to the essential framework that supports the app development cycle.
  • Topics covered include code signing, performance optimisation, shared libraries, CI/CD, fastlane, build speed, linting, scripts, Xcode upgrades, and more.
  • The role of Mobile Infrastructure is to streamline app development and simplify the lives of iOS engineers by addressing their daily challenges.
  • As development teams and codebases grow, a Mobile Infra team becomes crucial in maintaining a smooth workflow.

Challenges faced

  • Wide range of topics requiring diverse knowledge and expertise, with resources scattered across different teams, making it a steep learning curve.
  • Doubts about career choices and the necessary job skills.
  • Struggles with self-confidence and hesitancy in asking questions.

Key Takeaways

  • It's not necessary to know everything, but it's important to learn how to learn new things, and asking questions is a valuable tool.
  • Organise knowledge effectively.
  • Utilize an "unknown knowledge map" to identify what you don't know.
  • Take ownership of your knowledge gaps and take proactive steps to fill them.
  • Reflect on past experiences to learn how you approached seemingly impossible problems.
  • Remember that failure is a part of growth, even if it sounds cliché, it holds true.

Benefits of being a Mobile Infrastructure Engineer

  • Enhance your skills as a well-rounded engineer, gaining expertise in various areas.
  • Explore opportunities in open-source software (OSS), allowing you to learn new languages and contribute to the community.
  • Automate repetitive and frustrating tasks, identifying bottlenecks and resolving them through the use of scripts.

Session 3.- Technical Topic: Getting started with XCode Cloud

by ****Pol Piella Abadia

Senior software engineer at the BBC

CI/CD stands for Continuous Integration and Continuous Delivery/Deployment. It is a set of practices and methodologies in software development that aims to automate and streamline the process of building, testing, and delivering software.

Benefits of CI/CD:

  • Automate complex processes like generating code signing certificates and provisioning profiles with tools like fastlane match.
  • Schedule repetitive tasks for improved efficiency.
  • Provide flexibility and scalability in the software development process.
  • Guard against vulnerabilities by updating dependencies promptly.
  • Enforce code style to maintain consistency and readability.

Insights from indie developers: Xcode Cloud can be valuable for small personal projects. Despite initial concerns about time investment, the automated tasks it provides can save significant effort in the long run. Indie developers can benefit from Xcode Cloud by easily deploying their app on TestFlight and setting up pipelines with minimal effort.

What is XCloud

Xcode Cloud, Apple's integrated CI/CD service, is deeply integrated into Xcode and App Store Connect. It was introduced by Apple during WWDC21.

To access the source code, Xcode Cloud requires configuration of a remote repository.

How does it work?

Xcode Cloud operates on three key concepts: Products, Workflows, and Builds.

  • Products: They represent your app in Xcode Cloud and are directly linked to the app defined in App Store Connect.
  • Workflows: Multiple workflows are defined to specify actions for CI/CD processes.
  • Builds: These are executed on specific workflows to carry out the necessary tasks.

Define a workflow: Where: macOS version, XCode vesion, Environment variables and secrets



Starts conditions: Define a branch (push to a branch), PR, Tag or scheduled task.


Actions: build, test, archive, analyse


Post-actions: Deploy to Testlight for internal or external testing, send a slack message with the outcome.


Where the workflows run:

Workflows in Xcode Cloud are executed on macOS runners. Each workflow can have its own specific setup. There are multiple versions of Xcode and macOS available for selection.

Custom scripts

In Xcode Cloud, custom CI scripts can be used by placing them in the "ci_scripts" directory of the Xcode project. These scripts are executed by Xcode Cloud at different stages of the workflow based on specific names. For instance, "ci_post_clone.sh" runs after the repository is cloned, "ci_pre_xcodebuild.sh" runs before the build process starts, and "ci_post_xcodebuild.sh" runs after the build process is finished.

Example:



Pricing


In cloud execution, a computed hour equals 60 minutes. This implies that:

  • If you have 12 serial tasks, each taking 5 minutes, it will consume 1 computed hour, equivalent to 1 hour of actual time.
  • If you have 12 parallel tasks, each taking 5 minutes, it will also consume 1 computed hour, but only 5 minutes of actual time.
  • The free tier will be available until December 2023.

Key Takeaways:

Xcode Cloud, Apple's alternative for CI/CD, potentially offers significant advantages, particularly for side projects or independent developers aiming for a swift market launch. With less time dedicated to set-up and configuration complexities, a hassle-free and working CI/CD could prove invaluable.

However, there are some potential drawbacks to consider: It's reliant on Apple's infrastructure. This implies that deployment on local or third-party machines is not an option, increasing dependency on Apple Cloud machines.

While I haven't personally experienced this, the configuration could pose challenges when trying to install third-party software used in the release or post-build actions.

Session 4.- Soft Topic: So you just laid off so now what ?

by Zachary Brass

Former Meta employee (Instagram team)

Zachary Brass shared practical tips and advice for individuals who have been laid off from their jobs. Drawing from personal experience as a former Meta employee, Zachary offers valuable guidance on handling the challenges of unemployment and transitioning into a new job search. The tips cover various aspects, including self-care, networking with former colleagues, understanding entitlements, optimising job applications, managing schedules, developing personal "sthicks," and enhancing technical skills.

By following these recommendations, individuals can navigate the layoff period with resilience and confidence, increasing their chances of finding a new opportunity that aligns with their goals and aspirations.

Key Takeaways:

  • Take time to process the layoff before diving into job searching.
  • Connect with other laid-off employees from your former company for support and insights.
  • Understand your entitlements regarding taxes, retirement plans, and other benefits.
  • Treat job searching as your full-time occupation and create a productive home office setup.
  • Apply to a minimum number of jobs per day, including random positions for practice and confidence-building.
  • Establish healthy boundaries between work and personal activities to maintain a balanced schedule.
  • Keep Xcode open and readily available to check syntax or to avoid unexpected updates that may disrupt your interview process.
  • Develop reusable pieces of information (sthicks) for elevator pitches and job responsibilities.



  • Seek feedback after interviews to gain valuable insights.
  • Aways be prepared to negotiate terms.

END

In summary, I successfully accomplished one of my key goals while simultaneously having the opportunity to network with some truly extraordinary individuals.

It has been enlightening to learn that the challenges we encounter daily are prevalent within our industry. Importantly, I've gathered some critical insights from this conference which have already been shared amongst our team. We will be incorporating some of these key concepts into our operations in the near future. These takeaways could significantly enhance our collaboration.

I eagerly look forward to our next exciting venture.