<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Scott Berrevoets - Architecture &amp; Infrastructure</title><link>https://scottberrevoets.com/</link><description/><atom:link href="https://scottberrevoets.com/feeds/architecture-infrastructure.rss.xml" rel="self"/><lastBuildDate>Tue, 11 Aug 2026 00:00:00 -0700</lastBuildDate><item><title>The foundations of a mobile platform</title><link>https://scottberrevoets.com/2026/08/11/the-foundations-of-a-mobile-platform/</link><description>&lt;p&gt;In larger teams or companies, most people agree that the mobile platform is the
shared infrastructure an app and its features are built upon. In earlier stages,
that might simply mean "shared code and helper functions", but when the app and
team start scaling, the platform deserves a lot more …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Scott Berrevoets</dc:creator><pubDate>Tue, 11 Aug 2026 00:00:00 -0700</pubDate><guid>tag:scottberrevoets.com,2026-08-11:/2026/08/11/the-foundations-of-a-mobile-platform/</guid><category>Architecture &amp; Infrastructure</category><category>Platform Engineering</category><category>Architecture</category><category>Developer Experience</category></item><item><title>Managing code deprecations on iOS</title><link>https://scottberrevoets.com/2025/08/20/managing-code-deprecations-on-ios/</link><description>&lt;p&gt;A great manager I once worked with had been at Google for a while and poked fun
at an aspect of its engineering culture: any given service was either deprecated
or not yet ready for adoption. I spend a lot of my time working on mobile
platform development and over …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Scott Berrevoets</dc:creator><pubDate>Wed, 20 Aug 2025 00:00:00 -0700</pubDate><guid>tag:scottberrevoets.com,2025-08-20:/2025/08/20/managing-code-deprecations-on-ios/</guid><category>Architecture &amp; Infrastructure</category><category>Technical Debt</category><category>Platform Engineering</category></item><item><title>Flywheel of tech debt</title><link>https://scottberrevoets.com/2025/07/02/flywheel-of-tech-debt/</link><description>&lt;p&gt;Tech debt is often compared to financial debt, in that you're borrowing
development time now to pay it off with more development time later. When
"later" comes around, the development time needed to fix the issues introduced
earlier is too high so the new thing is also not built "correctly …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Scott Berrevoets</dc:creator><pubDate>Wed, 02 Jul 2025 00:00:00 -0700</pubDate><guid>tag:scottberrevoets.com,2025-07-02:/2025/07/02/flywheel-of-tech-debt/</guid><category>Architecture &amp; Infrastructure</category><category>Technical Debt</category><category>Architecture</category><category>Platform Engineering</category></item><item><title>Art of the state</title><link>https://scottberrevoets.com/2025/06/02/art-of-the-state/</link><description>&lt;p&gt;&lt;code&gt;@State&lt;/code&gt; plays a prominent role in any SwiftUI app, and for good reason: app
state is what ultimately drives the UI and how the user interacts with your app.
This has always been true, but SwiftUI embraces this reality with specific APIs
and a unidirectional data flow. UIKit-based apps or …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Scott Berrevoets</dc:creator><pubDate>Mon, 02 Jun 2025 00:00:00 -0700</pubDate><guid>tag:scottberrevoets.com,2025-06-02:/2025/06/02/art-of-the-state/</guid><category>Architecture &amp; Infrastructure</category><category>Architecture</category><category>Testing</category></item><item><title>Shifting the testing culture: Code coverage</title><link>https://scottberrevoets.com/2024/11/20/shifting-the-testing-culture-code-coverage/</link><description>&lt;div class="admonition note"&gt;
&lt;p class="admonition-title"&gt;Note&lt;/p&gt;
&lt;p&gt;This is the third post in a series on shifting our testing culture.&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;&lt;a href="https://scottberrevoets.com/2024/11/18/shifting-the-testing-culture-motivation/"&gt;Motivation&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="https://scottberrevoets.com/2024/11/19/shifting-the-testing-culture-infrastructure/"&gt;Infrastructure&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;Code coverage&lt;/li&gt;
&lt;/ol&gt;
&lt;/div&gt;
&lt;p&gt;Most people will say that code coverage is a measure of how well-tested your
code is. I prefer to say it's a measure of how &lt;em&gt;untested&lt;/em&gt; a codebase is. Take
this example …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Scott Berrevoets</dc:creator><pubDate>Wed, 20 Nov 2024 00:00:00 -0800</pubDate><guid>tag:scottberrevoets.com,2024-11-20:/2024/11/20/shifting-the-testing-culture-code-coverage/</guid><category>Architecture &amp; Infrastructure</category><category>Testing</category><category>Developer Experience</category><category>Engineering Culture</category></item><item><title>Shifting the testing culture: Infrastructure</title><link>https://scottberrevoets.com/2024/11/19/shifting-the-testing-culture-infrastructure/</link><description>&lt;div class="admonition note"&gt;
&lt;p class="admonition-title"&gt;Note&lt;/p&gt;
&lt;p&gt;This is the second post in a series on shifting our testing culture.&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;&lt;a href="https://scottberrevoets.com/2024/11/18/shifting-the-testing-culture-motivation/"&gt;Motivation&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;Infrastructure&lt;/li&gt;
&lt;li&gt;&lt;a href="https://scottberrevoets.com/2024/11/20/shifting-the-testing-culture-code-coverage/"&gt;Code coverage&lt;/a&gt;&lt;/li&gt;
&lt;/ol&gt;
&lt;/div&gt;
&lt;p&gt;This second article goes a bit deeper into the testing infrastructure we built
over the years to optimize the ergonomics and developer experience as much as
possible.&lt;/p&gt;
&lt;p&gt;Our initial test suites only …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Scott Berrevoets</dc:creator><pubDate>Tue, 19 Nov 2024 00:00:00 -0800</pubDate><guid>tag:scottberrevoets.com,2024-11-19:/2024/11/19/shifting-the-testing-culture-infrastructure/</guid><category>Architecture &amp; Infrastructure</category><category>Testing</category><category>Architecture</category><category>Developer Experience</category></item><item><title>Migration strategies in large codebases</title><link>https://scottberrevoets.com/2022/11/15/migration-strategies-in-large-codebases/</link><description>&lt;p&gt;Code migrations are a fact of life for large codebases. New technologies pop up,
platforms see improvements, and programming languages get new features you might
want to adopt. Not performing these migrations and keeping up with the times is
simply not an option in most cases. While some migrations are …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Scott Berrevoets</dc:creator><pubDate>Tue, 15 Nov 2022 00:00:00 -0800</pubDate><guid>tag:scottberrevoets.com,2022-11-15:/2022/11/15/migration-strategies-in-large-codebases/</guid><category>Architecture &amp; Infrastructure</category><category>Technical Debt</category><category>Engineering Culture</category></item><item><title>Third-party libraries are no party at all</title><link>https://scottberrevoets.com/2022/07/15/third-party-libraries-are-no-party-at-all/</link><description>&lt;p&gt;&lt;em&gt;What better way to end the week than with a hot take?&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;In my 8 years at Lyft, product managers or engineers have often wanted to add
third-party libraries to one of our apps. Sometimes it’s necessary to integrate
with a specific vendor (like PayPal), sometimes it’s to …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Scott Berrevoets</dc:creator><pubDate>Fri, 15 Jul 2022 00:00:00 -0700</pubDate><guid>tag:scottberrevoets.com,2022-07-15:/2022/07/15/third-party-libraries-are-no-party-at-all/</guid><category>Architecture &amp; Infrastructure</category><category>Technology Adoption</category><category>Technical Debt</category></item><item><title>iOS Architecture at Lyft</title><link>https://scottberrevoets.com/2021/10/14/ios-architecture-at-lyft/</link><description>&lt;p&gt;June 30, 2014 was my first day at Lyft as the first iOS hire on the ~3 person
team. The app was written in Objective-C, and the architecture was a 5000-line
nested switch statement.&lt;/p&gt;
&lt;p&gt;Since then, the team has grown to about 70 people and the codebase to 1.5M …&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Scott Berrevoets</dc:creator><pubDate>Thu, 14 Oct 2021 00:00:00 -0700</pubDate><guid>tag:scottberrevoets.com,2021-10-14:/2021/10/14/ios-architecture-at-lyft/</guid><category>Architecture &amp; Infrastructure</category><category>Architecture</category><category>Platform Engineering</category></item></channel></rss>