"Design is how it works," Steve Jobs famously said. At Flowstate Industries, this principle guides everything we build. This post explores our approach to creating iOS apps that feel right to use—apps where thoughtful design is invisible because everything just works.
Design is How It Works
The best designs disappear. When software works perfectly, you don't notice the interface—you're fully absorbed in what you're trying to accomplish. This is the goal: apps so well-designed that users achieve flow state without friction.
Achieving this requires a specific mindset. Design isn't decoration applied after engineering. Design is the structure of the product itself—how information is organized, how actions flow, how feedback is communicated.
At Flowstate Industries, design and development aren't separate phases. They're interwoven throughout. I'm designing while I code and coding while I design. SwiftUI actually encourages this—building interface in code makes iteration between design and implementation seamless.
Every interaction is a design decision:
- How does adding a country feel? Is it immediate and satisfying, or slow and uncertain?
- What happens when something goes wrong? Does the app communicate clearly, or leave users confused?
- How do users discover features? Are capabilities obvious, or hidden in menus?
- What's the emotional response to using the app? Do users feel competent and successful, or frustrated and stuck?
These questions shape our apps more than any feature list.
Starting with the User, Not Features
A common trap in app development: starting with features you want to build rather than problems users need solved.
When I started Worldly, I didn't begin with "I want to build a travel tracking app." I began with a specific frustration: existing apps required accounts, synced to clouds I didn't trust, and didn't respect my privacy. The feature set emerged from solving that problem.
Our design process starts with questions:
Who is this for? Worldly is for travelers who want to track their journeys privately. Not social travelers who want to share. Not business travelers tracking expenses. Understanding who we're not building for is as important as who we are.
What do they actually need? Users want to record where they've been and relive those memories. They don't need social features, gamification, or complicated statistics. Identifying core needs prevents feature bloat.
What frustrates them about existing solutions? Mandatory accounts, privacy concerns, complicated interfaces, subscription fatigue. These frustrations become design requirements—things we specifically avoid.
What does success look like? A user who opens the app, logs their recent trip, sees their travel history visualized, and smiles. That emotional outcome guides every decision.
Starting from users rather than features creates coherent products. Every feature connects to user needs. Nothing exists simply because we could build it.
Native iOS Development: Why It Matters
Flowstate Industries builds native iOS apps using Swift and SwiftUI. This isn't the easiest path—cross-platform frameworks could theoretically let us ship to iOS and Android simultaneously. We chose native anyway.
Here's why:
Performance: Native apps are fast. No JavaScript bridge, no interpreted layer, no abstraction overhead. Animations run at 60fps. Interactions feel immediate. The app never feels sluggish.
Platform Integration: iOS has deep capabilities that cross-platform frameworks struggle to access. System integration feels seamless because it actually uses system APIs. Widgets, shortcuts, iCloud sync, accessibility features—they all work properly.
Design Language: iOS has a design language users understand. Navigation patterns, gesture meanings, interface conventions—users bring expectations. Native apps meet those expectations naturally. Cross-platform apps often feel subtly wrong.
Future-Proofing: When Apple releases new iOS versions, new devices, or new capabilities, native apps adapt immediately. Cross-platform frameworks often lag behind, sometimes for years.
Quality Ceiling: The best iOS apps are native. That's not coincidental. Native development provides control that frameworks abstract away. That control enables excellence.
The tradeoff is limited reach—we're iOS-only for now. But we'd rather make one excellent iOS app than two mediocre cross-platform apps.
The Details That Create Delight
Great software is built from thousands of small decisions. Users may not consciously notice these details, but they feel them. An app where every detail is considered feels polished. An app where details are neglected feels cheap.
Here are examples from Worldly:
Haptic Feedback: When you mark a country as visited, a subtle haptic confirms the action. The vibration matches the visual animation. This tiny detail makes interactions feel physical and satisfying.
Animation Timing: The globe spins to show your newly visited country with carefully tuned animation curves. Too fast feels abrupt. Too slow feels sluggish. The timing is calibrated to feel natural.
Loading States: When data is processing, users see purposeful loading indicators, not blank screens. The app always communicates its state.
Error Recovery: When something goes wrong, error messages explain what happened and what users can do. No cryptic error codes. No dead ends.
Accessibility: VoiceOver support, Dynamic Type, reduced motion preferences—users with accessibility needs deserve the same quality experience.
Empty States: When you haven't logged any travels yet, the empty state isn't just blank. It welcomes you and guides first actions.
None of these individually make or break the app. But collectively, they're the difference between software that feels crafted and software that feels assembled.
Iteration Through Real Usage
No amount of planning survives contact with real users. Features that seemed essential go unused. Interactions that felt obvious confuse people. Edge cases you never considered become common patterns.
Our design process embraces this reality:
Ship Early: Get real versions into real users' hands as soon as basic functionality works. Waiting for perfection means waiting forever—and building the wrong thing.
Watch Usage: Analytics (privacy-respecting, aggregate only) reveal how features are actually used. Where do users spend time? What features are ignored? Where do they get stuck?
Listen to Feedback: User feedback through reviews, support emails, and TestFlight comments provides qualitative insight analytics can't. When multiple users report the same confusion, that's a design flaw to fix.
Iterate Rapidly: SwiftUI enables fast iteration. Spot a usability problem, fix it, ship an update. The app improves continuously rather than in big, risky releases.
Kill Darlings: Some features don't work despite our best intentions. When usage data shows something isn't landing, we remove it. Simplicity is more valuable than feature count.
Worldly today is significantly different from the first version. The globe interaction has been refined through dozens of iterations. Features have been added and removed. The design evolved through real usage, not theoretical planning.
Tools and Process for Solo Developers
Building quality iOS apps as a solo developer requires efficiency. Here's the practical toolset and process that makes it possible:
Development Environment:
- Xcode as the core IDE
- SwiftUI for declarative, iterative UI development
- SF Symbols for consistent, high-quality icons
- Swift native frameworks wherever possible
Design Tools:
- Figma for occasional mockups, though SwiftUI makes direct prototyping faster
- Apple's Human Interface Guidelines as the design foundation
- Real device testing throughout development, not just Simulator
Process Approach:
- Design and development happen together, not sequentially
- Build the smallest useful version first, then expand
- Test on device constantly—Simulator misses haptics, performance, and feel
- Beta test through TestFlight before public release
Quality Standards:
- Every feature gets real device testing
- Accessibility is checked before shipping
- Performance is profiled to catch regressions
- Edge cases are handled, even if rarely triggered
The solo constraint forces focus. Without a team to distribute work, every feature competes directly against every other feature for the most limited resource: time. This scarcity prevents bloat and ensures only genuinely valuable work gets done.
The Craft of Software
There's a Japanese concept, kodawari, that describes the uncompromising pursuit of perfection in craft. Software at its best embodies this spirit—attention to detail not for external validation, but because the craft itself demands it.
At Flowstate Industries, we build software this way. Not because users will consciously notice every considered detail, but because they'll feel the difference. An app where every interaction has been refined feels different from one assembled carelessly. That difference is what we're pursuing.
If you've used Worldly and noticed something that could be better, tell us. If you're building your own iOS apps and want to discuss craft, reach out. The pursuit of excellent software is better shared than solitary.
Design is how it works. We're working to get it right.