Reach
Both Android and iOS have broad reach.
- Android is the leader globally
Android (global) 72.37% — iOS (global) 26.98% - iOS is the leader in US
Why build for native iOS (not KMP?)
Why build for native iOS with Apple toolchain when we have Kotlin Multiplatform technology?
One issue with Kotlin Multiplatform technology …
Apple understands it is an innovation company.
visionOS has great potential.
KMP is maybe not going to support visionOS (for now)
We can’t afford having any layers between us and innovation.
AI/ML mind blowing 🤯 projects Android & WearOS | iOS & watchOS & visionOS | Robotics & IoT (Rust):
And if we have issues we hammer on Apple … and they must respond!
In these series of articles we look at Android & iOS dev in one thought.
Once you choose the language the rest just follows
Key: “→” means “leads to”
Choosing: Language → Architecture → Package Manager → Database → Declarative UI → Development Env. → Testing → Frameworks → Stores
Android & iOS Dev: Thinking Holistically
This series of articles dives into the world of mobile development, exploring both Android and iOS development from a unified perspective. We’ll guide you through the essential decisions and tools you’ll encounter, helping you think strategically about building mobile apps for both platforms.
Beyond Language: A Connected Development Journey
While choosing a language is an important first step, it’s just the beginning. We’ll trace the interconnected development process, showing how each decision leads to the next:
- Language: Kotlin & Swift
- Architecture: OOP & POP paradigms
- Package Management: Gradle / TOML (Android) & Swift Package Manager (iOS)
- Data Persistence: RoomDB (Android) & SwiftData (iOS)
- User Interface: Compose with Material Design 3 (Android) & SwiftUI with Apple HIG (iOS)
- Development Environment: Android Studio & Xcode
- Testing: Testing with Hilt (Android) & XCTest (iOS)
- App Functionality: Frameworks for payment, sensors, fitness, AR/VR, and AI/ML
- Deployment: Navigating the Google Play Store and Apple App Store
Structured Learning for Maximum Impact
We’ve divided this series into three comprehensive sections to ensure you gain a well-rounded understanding of native mobile AndiOS development:
Section 1: AndiOSDev Foundation
- Languages & Features: Kotlin & Swift, including key features like functions, extensions, concurrency (coroutines/Swift structured concurrency).
- Architecture Paradigms: Object-Oriented Programming (OOP) and Protocol-Oriented Programming (POP).
- Package Management: Learn how to manage dependencies for each platform.
Section 2: AndiOSDev Building
- Data Persistence: Dive into the world of databases with RoomDB (Android) and SwiftData (iOS).
- User Interface: Explore the power of declarative UI with Compose and SwiftUI, including state management and navigation.
- Development Environment: Set up your development environment with Android Studio or Xcode, and explore additional tooling options.
- Project Structures: Understand how to organize your project effectively.
Section 3: AndiOSDev Deployment
- App Functionality: Explore a range of frameworks to enhance your app’s capabilities in various domains like payments, sensors, and AR/VR, AI/ML.
- Testing: Learn best practices for testing your app with Hilt Test (Android) and XCTest (iOS).
- Deployment: Learn the ropes of publishing your app on the Google Play Store and Apple App Store.
By delving into these topics, you’ll gain a holistic understanding of mobile development and be well-equipped to build native platform applications specializing in both Android and iOS.
This should be recored …
~Ash
Jetpack Compose (Kotlin Flow) & SwiftUI (Combine Framework)
A Word About Mobile App Architecture
Not All Architectures Are the Same
Choosing the right architecture is crucial in mobile app development, as it significantly impacts the app’s testability, scalability, and maintainability. Here’s a comparison of some common architectural patterns:
- Model-View-Controller (MVC): This traditional pattern divides the application into three components — Model, View, and Controller. While it’s straightforward, MVC is often not easily testable because the Controller can become a catch-all for logic, making unit testing complex and cumbersome.
- Model-View-Presenter (MVP): MVP separates the Presenter from the View, enhancing testability by allowing developers to test the Presenter independently of the View. However, it is not inherently reactive, lacking built-in support for real-time data updates and reactive programming paradigms.
- Model-View-ViewModel (MVVM): MVVM introduces the ViewModel, which acts as an intermediary between the Model and the View. This architecture supports testability and reactivity, enabling automatic UI updates when the underlying data changes through data binding. MVVM employs unidirectional data flow, but it doesn’t utilize an immutable intent channel. This means that while data flows in one direction — from the Model to the ViewModel to the View — the state can still be mutable, which can complicate state management and debugging.
- Model-View-Intent (MVI): MVI addresses the shortcomings of previous patterns by incorporating testability, reactivity, and immutable state. It uses unidirectional data flow and an immutable intent channel, making state management more predictable. Changes in the state are modeled as immutable data objects, which simplifies tracking state changes over time and enhances debugging capabilities.
Understanding these differences helps developers select an architecture that aligns with their app’s complexity and future scalability needs.
Android
In the early days of Android development, there was a notable lack of guidance on app architecture. Without established best practices, developers resorted to their own methodologies, leading to a fragmented landscape of languages, tools, and design principles. This inconsistency resulted in many poorly designed apps populating the Play Store. Unfortunately, users often blamed Android itself, remarking that “Android sucks,” rather than recognizing the individual app shortcomings. Thankfully, Google now provides clear guidelines and best practices, helping developers create robust, consistent, and high-quality Android applications.
Learn More:
iOS
Initially, Apple advocated for the Model-View-Controller (MVC) pattern, which proved insufficient for complex applications. Many developers shifted to their own versions of Model-View-ViewModel (MVVM). However, with the introduction of new tools like Swift, SwiftUI, structured concurrency, Combine, and SwiftData, uncertainty has grown around the proper way to architect apps today. The recent addition of SwiftData exacerbates this confusion, as it doesn’t integrate well with MVVM. Apple now has an opportunity to provide the developer community with clear, cohesive architectural guidance that leverages the latest technologies — Swift, SwiftUI, structured concurrency, SwiftData, SwiftCharts, and Swift Testing.
Without this guidance, developers are left to guess how their architectures will align with future advancements in the Apple ecosystem. It’s crucial for Apple to define best practices to ensure the development of robust and maintainable iOS applications moving forward.
Why This Matters: An Example
Consider two iOS experts with differing views on using ViewModels:
- Mohammad Azam, an iOS expert and educator, advises against using a ViewModel.
- Paul Hegarty, an iOS expert and Stanford instructor, consistently uses a ViewModel, adhering to the MVVM pattern.
Who’s right? If you’re using SwiftData, Azam’s approach is advantageous because SwiftData doesn’t work well with MVVM. Adhering to Azam’s guidance makes transitioning to SwiftData seamless. On the other hand, if you’ve followed Hegarty’s MVVM approach, integrating SwiftData becomes challenging.
In retrospect, it seemed negligent for Google/Android not to provide solid architectural advice in the past, and we’re now witnessing a similar situation with Apple/iOS. Without insight into Apple’s roadmap, how can developers make informed, long-term architectural decisions?
By understanding the nuances of different architectural patterns and staying informed about platform developments, developers can make better choices that will stand the test of time. It’s essential for platform providers like Apple and Google to offer clear architectural guidelines to support the developer community in building robust and future-proof applications.
This was shared with the community here:
Finally, I want to touch on a couple of specific comments. First, Siamak (Ash) Ashrafi on how he has seen iOS and Android development switch places when it comes to guidance on app architecture. Apple used to firmly encourage an MVC approach, but that has gone these days. Whereas, Android:
In the early days, Android developers faced a lack of guidance on app architecture. With no best practices provided, every developer implemented their own approach, leading to fragmented use of languages, tools, and design principles. This inconsistency resulted in many poorly designed apps on the Play Store, and unfortunately, the blame often fell on Android itself rather than the individual apps — users simply said, “Android sucks.” Fortunately, Google now offers clear guidelines and best practices, helping developers create robust, consistent, and high-quality Android apps.
He offered a link to Google’s Guide to app architecture and I enjoyed reading it. I thought I agreed with Apple’s recent stance of being completely architecture agnostic, especially when it comes to SwiftUI code. It’s hard to give generic advice about app architecture, but this guide does a great job. They have a whole learning pathway on the subject, too.
