Ten Years, Three Apps, One Evolution

From Objective-C to SwiftUI, from CocoaPods chaos to Swift Package Manager, I've built three iOS apps that span a decade of platform evolution. Here's what breaking production taught me about dependency management, authe

I've spent the last decade building iOS applications, and my GitHub repositories tell a story that every product engineer will recognize: the relentless march of platform evolution, the pain of third-party integrations, and the constant tension between shipping fast and building right. Three projects— • Stormy-Travel-Time (2015-2026): A weather and travel app born in the Objective-C era • GoingVegan (2023-2026): A vegan lifestyle companion with restaurants, recipes, and gamification • PetSafe (2026): A pet food safety scanner leveraging barcode APIs Together, these apps represent over 150 commits, 23,000 lines of Swift and Objective-C, and countless hours debugging authentication flows that only fail in production. Let me show you what I learned.

The Three Apps: A Technical Overview Stormy-Travel-Time: The Legacy Survivor Starting in 2015, Stormy-Travel-Time was built when UIKit was king and Objective-C was still the lingua franca. Over 57 commits spanning 10 years, this app evolved through multiple architecture paradigms. The git history reads like a timeline of iOS development itself: initial Objective-C implementation, Swift migration, experiments with ReactiveCocoa, eventual removal of reactive patterns for direct URLSession calls, and the never-ending battle with Google Maps SDK binary size (more on that later). Key stats: 57 commits, ~3,200 lines of code (mixed Swift/Objective-C), UIKit-based architecture, Google Maps integration, OpenWeather API integration.

GoingVegan: The Maturing Product Launched in 2023 during the SwiftUI renaissance, GoingVegan represents my transition to thinking like a product engineer. With 89 commits over three years, this app includes sophisticated features: map-based restaurant discovery with Yelp integration, AWS-backed recipe database, streak mechanics and gamification, Sign in with Apple and Google authentication, subscription management and paywalls, and accessibility-first design patterns. The commit messages tell a story of iteration: multiple sign-in integration attempts, performance optimizations for map rendering, extensive accessibility work, and data synchronization challenges between Firebase Auth and CoreData. Key stats: 89 commits, ~7,600 lines of Swift, SwiftUI + CoreData, multi-provider authentication, AWS API integration.

PetSafe: The Modern Sprint Built in just four weeks (January 2026 - February 2026), PetSafe is my most recent project and represents the state of the art in iOS development. With 14 commits and ~13,000 lines of Swift, this app leverages modern tooling: SwiftUI + SwiftData (Apple's newest persistence framework), barcode scanning with AVFoundation, USDA and OpenFoodFacts API integration, subscription infrastructure with StoreKit 2, and test-driven development from day one.

Despite being the newest, PetSafe is also the largest codebase—a testament to how much infrastructure modern iOS apps require out of the box.

The Patterns That Emerged: Common Challenges Across a Decade Analyzing the git history across all three projects revealed five recurring challenges that transcend any single app or technology choice.

1. Dependency Management: The Silent Productivity Killer Stormy-Travel-Time's commit history is a graveyard of dependency management attempts. The app went through CocoaPods, experimented with Carthage to reduce binary bloat, attempted manual framework integration, then circled back to CocoaPods. Each migration consumed days of work and introduced new failure modes.

The data backs this up: research shows CocoaPods alters project files and introduces merge conflicts, while SPM produces binaries approximately 20% smaller than other solutions. By 2025, CocoaPods entered maintenance mode, with no new versions planned past Q2 2026. This means Stormy-Travel-Time's 10-year journey tracks the entire lifecycle of iOS dependency management tools from inception to deprecation.

PetSafe, built entirely with Swift Package Manager, shows how much easier life has become. No workspace files, no pod installs, just declare dependencies and go. But GoingVegan still uses CocoaPods for some Firebase dependencies, creating a hybrid approach that works but feels like technical debt.

2. Third-Party SDK Integration: When 'Just Use Their Library' Isn't Simple The Google Maps problem: Stormy-Travel-Time has multiple commits trying to shrink the Google Maps SDK, which adds an average of 5.7 MB to IPA size and 18 MB to install size. The commit messages are telling: "Shrinking GoogleMaps size," "downgrading to googlemaps version 10.5.1 in hopes of smaller framework size," "removing cocoapods and manually adding frameworks." None of these worked. The SDK is just big.

The authentication integration maze: GoingVegan's git history shows the pain of authentication integration: "Got Sign In With Apple working" (success!), "Fixed the data issues with sign out" (oh no), "Cleaned up code and got google sign in to display calendar correctly" (wait, the calendar?). Authentication isn't just about OAuth flows—it's about token management, account deletion requirements, handling partial user information, and dealing with the fact that Sign in with Apple only returns credentials on first sign-in. According to recent research, 85% of developers face challenges managing API response errors, and authentication flows are the perfect storm of state management, security requirements, and platform-specific quirks.

3. UI Consistency Across Devices: The Eternal Screen Size Battle All three apps have multiple commits about layout issues, screen size adjustments, and cleaning up UI for "all devices." GoingVegan alone has: "Fixing ui on other screens so it dynamically adjusts to screen size," "Fixing screen size issues on log in screen," "cleaning up home screen so it works with all devices." SwiftUI's promise of adaptive layouts helps, but the reality is messier. Simulator testing isn't enough—you need to test on actual devices with different screen sizes, safe area insets, and dynamic type settings.

4. Data Persistence and State Management: The Synchronization Nightmare GoingVegan's "Fixed the data issues with sign out" and "Potential fix for unloaded code. Will need to continue to test and see" commits highlight a fundamental challenge: keeping local state synchronized with remote data, authentication state, and UI state simultaneously. Using CoreData, I hit issues with context threading, optimistic UI updates that failed to sync, and the classic problem of signing out while network requests are in-flight. PetSafe's use of SwiftData simplifies some of this, but introduces new challenges around query performance and @Query property wrapper behavior.

5. Build Warnings and Technical Debt: Death by a Thousand Papercuts Across all three projects, there are countless commits about "cleaning up warnings," "warning hunting," "resolving all errors," and "correcting warnings." Warnings are insidious because they're easy to ignore until they aren't. In Stormy-Travel-Time, ignoring forced unwrapping warnings led to production crashes. In GoingVegan, deprecation warnings meant entire sections of code needed refactoring when Firebase updated their API. The lesson: treat warnings like errors, or pay the technical debt later with interest.

The Hardest Challenge: Platform Migration Under Pressure If you asked me to rank the challenges, dependency management was the most persistent, authentication was the most frustrating, but platform migration was the hardest. Here's why.

Stormy-Travel-Time started in Objective-C in 2015. By 2020, Swift was the clear future, and the codebase needed to evolve. The commit "First swift update" marks the beginning of a multi-month migration that touched every file. The challenge wasn't the language syntax—it was the architectural decisions baked into the Objective-C code that didn't translate cleanly.

Objective-C encourages massive view controllers, manual memory management thinking, and dynamic typing. Swift wants value types, protocol-oriented design, and compile-time safety. Bridging these worldviews while keeping the app functional for users meant running a mixed codebase for years. The git history shows the reality: "resolving all errors. Now targeting warnings for cleanup," "resolving all issues except googlemaps error," "All but 3-4 warnings. Still builds and works."

The GoogleMaps error that persisted across multiple commits? It was a bridging header issue that only manifested in release builds. Tracking that down required understanding the Objective-C runtime, Swift interop, and Xcode's build system internals.

This experience shaped how I approached GoingVegan and PetSafe. Both were built Swift-only from day one, with clear architecture boundaries and value-type-first design. When SwiftUI emerged, I could adopt it incrementally in GoingVegan rather than facing another big-bang rewrite.

What Ten Years Taught Me About Product Engineering 1. The platform will change faster than your app In 2015, Objective-C was standard. In 2020, SwiftUI was the future. In 2026, we have SwiftData, async/await, and Observation framework. Your 10-year app will outlive multiple paradigm shifts. The engineers who thrive are those who can evaluate new technologies pragmatically: not every shiny new framework is worth adopting, but ignoring platform evolution means your codebase becomes legacy before your product does.

2. Third-party dependencies are technical debt from day one That convenient SDK that saves you two weeks of work? It's now a permanent fixture in your binary, a source of build warnings when they deprecate APIs, and a breaking change when they decide to rewrite their authentication flow. According to research, 70% of developers prefer URLSession over third-party networking libraries for this reason. The native solution might be more verbose, but it won't break when a random startup pivots or shuts down.

3. Authentication is never 'just authentication' Every app in this analysis had authentication challenges. It's not about OAuth flows—those are documented. It's about: handling partial credentials from Sign in with Apple, synchronizing auth state across CoreData, Firebase, and local caches, dealing with 503 errors from Apple's servers during peak times, implementing account deletion to comply with App Store requirements, and managing token refresh without breaking the user experience. Plan for auth to take 3x longer than you think.

4. Commit messages are documentation for future you "Potential fix for unloaded code. Will need to continue to test and see" is a commit message from GoingVegan. Six months later, I came back to this code with a similar bug and had no idea what "unloaded code" meant. Good commit messages explain the why, not just the what. They're breadcrumbs for when you inevitably return to code you've forgotten.

5. Product thinking beats technical perfection PetSafe is the largest codebase at 13,000 lines, but it was built in four weeks. GoingVegan is smaller but took three years. The difference? PetSafe had a tight scope, clear user value, and ruthless prioritization. GoingVegan tried to be a complete vegan lifestyle platform from day one. The best product engineers know when to ship a focused v1 and when to build infrastructure for scale. The git history shows my evolution: early commits are feature-heavy, later commits are more surgical, more tested, more focused on user value.

Conclusion: Product Engineering as a Practice These three apps represent more than a decade of iOS development—they represent the evolution from developer to product engineer. The difference isn't just about writing better code (though that helps). It's about understanding that every technical decision has product implications. Choosing CocoaPods over SPM affects binary size, which affects download rates, which affects acquisition cost. Implementing authentication affects onboarding friction, which affects activation rates, which affects retention. Ignoring accessibility affects your addressable market.

The hardest challenges weren't the technical ones—they were the decisions about what to build, when to refactor, and when to ship with known issues. That's product engineering: the messy intersection of code, user needs, business constraints, and platform evolution.

If you're a product manager reading this, I hope you see that engineers who understand git history, dependency bloat, and authentication flows also understand user friction, technical debt, and trade-offs. If you're an engineer reading this, I hope you see that caring about these things doesn't make you less technical—it makes you more valuable.

The next 10 years will bring new frameworks, new paradigms, and new challenges. But the fundamentals remain: ship value, pay down debt, evolve with the platform, and leave the codebase better than you found it. One commit at a time.

Ten Years, Three Apps, One Evolution

Share Post