Building Blocks: Learnings from the Competitor Analysis

Asgardeo Android SDK Development Journey — Episode 2

Achintha Isuru
3 min readMay 13, 2024
Photo by Our Life in Pixels on Unsplash

In the previous episode of my development journey of the Asgardeo Android SDK, I discussed the competitor analysis that we conducted on mobile SDKs for app-native authentication.

If you haven’t read it, you can find it at the link below,

https://achinthaisuru444.medium.com/a-deep-dive-into-mobile-sdks-for-app-native-authentication-a-competitor-analysis-d315f0ba89b9

Today, in this episode, let’s go into the architectural decisions we made during the development of the Android SDK.

Native First Approach

Our competitor analysis revealed that while the current trend is towards cross-platform development tools like Flutter and React Native, the industry still predominantly focuses on native development using vanilla Android and iOS, due to their stability and support. Therefore, as an organization committed to serving our customers, we decided to prioritize native programming languages.

Since Android is the dominant platform globally, we chose to develop an Android SDK first, followed by iOS SDK development, and eventually SDKs for cross-platform development technologies.

Core vs. UI Kit

Most competitors opted for a core SDK that focuses on core functional details rather than a UI kit. This is because customers who choose app-native authentication often prefer to develop their own UIs rather than use a provided UI by a third party. Following this insight, we decided to prioritize the development of the core SDK first, with plans to develop the UI kit afterward.

Project Overall Design

Overall project architecture

We have designed the overall mobile SDKs architecture as depicted in the diagram above. This architecture enables us to implement app-native authentication logic in both Android and iOS, and then reuse this logic in cross-platform technologies, simplifying the development process.

Repository Architecture

While most competitors develop their SDKs in standalone repositories, we decided to use a mono repository for all mobile SDKs. This decision was made to ease the propagation of changes between native and cross-platform SDKs, as they will all reside in the same repository. One challenge we anticipate is deployment, as various SDKs need to be published on different platforms (e.g., Android to Maven Central and Flutter to pub.dev). We plan to address this challenge by implementing separate GitHub actions for each technology.

Conclusion

Our architectural decisions reflect a keen understanding of industry trends and user preferences. Prioritizing a native-first approach and core functionality lays a solid foundation for customization. The adoption of a monorepo streamlines integration across platforms. Stay tuned for the next episode as we translate these insights into actionable steps for an enhanced authentication experience.

--

--