AllTheThings (iOS)

Purpose

Rebuilt the AllTheThings inventory concept as a native iOS app in Swift/SwiftUI, after the original Flutter version. The motivation: see how the same idea feels when built with native tools — platform APIs, system integrations, and the iOS-specific UX that cross-platform frameworks approximate but never fully replicate.

Stack

What I Learned

• Flutter pros: single codebase for iOS and Android, hot reload for instant UI iteration, Dart is easy to learn, massive widget library, consistent rendering across platforms (your app looks identical everywhere). Flutter cons: platform-specific features require plugins or platform channels, the app binary is larger (~20MB minimum), deep OS integrations (Shortcuts, Widgets, ShareSheet) require native code anyway, and Flutter apps never feel quite native on either platform — subtle differences in scroll physics, navigation gestures, and text selection.
• Native iOS (Swift/SwiftUI) pros: full access to every Apple API without bridges, apps feel native because they ARE native, SwiftUI integrates seamlessly with system features (widgets, Shortcuts, ShareSheet, iCloud sync, Handoff), Xcode's Instruments profiling is unmatched, and App Store reviewers tend to be more lenient with native apps that follow HIG (Human Interface Guidelines). Native cons: iOS only (no Android from the same codebase), SwiftUI is still maturing (some layouts require UIKit fallbacks), and you need a Mac to develop.
• CoreData (Apple's object graph persistence framework) vs. Firebase/Firestore: CoreData is local-first with optional CloudKit sync. Your data lives on the device, syncs to iCloud when available, and works offline by default. Firebase is cloud-first with offline caching. For a personal inventory app that should work in your basement with no signal, CoreData + CloudKit is the architecturally correct choice.
• The same feature (cataloging items with categories, photos, and values) took less code in SwiftUI than in Flutter because SwiftUI has native access to the camera (PhotosPicker), persistence (CoreData/@FetchRequest), and list rendering (List with swipe actions built in). Flutter achieves the same result but through plugins and wrappers that add layers of abstraction. Each layer is a potential point of failure or version mismatch.
• The decision framework: use Flutter when you need both platforms and your app is primarily UI-driven (social media, content display, e-commerce). Use native when you need deep platform integration (health data, system widgets, NFC, AR), performance-critical rendering (games, video), or when your user base is exclusively one platform. AllTheThings — a personal tool for one person on one phone — is the clearest case for native.

Key Insights

• Building the same app twice — once in Flutter, once in Swift — is the most effective way to form a genuine opinion about cross-platform vs. native. Most developers argue from theory or tribal loyalty. Building both forces you to compare on substance: development speed, platform feel, feature access, maintenance burden, and user experience. The opinion you form from building is more nuanced than the opinion you form from reading.
• Flutter and native iOS are not competitors — they are tools for different situations. The Potatuhs ecosystem uses both: Flutter for cross-platform apps and games (Hot Potato Games), native Swift for iOS-specific tools and experiments. Choosing one "forever" is the wrong framing. Choosing the right one for each project is the skill.
• The AllTheThings concept surviving a platform migration (Flutter → Swift) without changing the product vision confirms that the idea is separable from the technology. The inventory concept is sound regardless of the stack. This is the test of a good product idea: it should make sense in a sentence that contains no technical words. "Catalog everything you own and share it with people you trust" works in Flutter, Swift, React Native, or pen and paper.